CDC2NET - beliebigen USB-CUL/TUL/EUL per ESP32-S3 ins Netz bringen

[tostmann]

Kurz worum's geht: CDC2NET macht aus einem ESP32-S3 einen USB-Host, der einen angesteckten USB-Stick (CUL/TUL/EUL, nanoCUL & Co.) transparent als raw-TCP-Port ins Netz legt. In FHEM bindet man ihn wie einen lokalen CUL ein, nur über host:port — im Prinzip die Rolle eines CUN, aber mit dem Stick, den man eh schon hat:

Code Auswählen Erweitern

define CUL_0 CUL cdc2net.local:2329 1234
Die Firmware des Sticks bleibt dabei unangetastet (culfw/a-culfw läuft weiter); CDC2NET trägt nur dessen serielle Leitung über WLAN.

Was heute funktioniert:

• native CDC-ACM: klassischer CUL (LUFA/ATmega32U4), C3/C6-USB-Serial-JTAG
• USB-Seriell-Bridges über die VCP-Treiber: FTDI, CH340/CH341, CP210x (inkl. echtem Setzen der Baudrate)
• Per-Port-Serial-Config (Baud/Bits/Parität) im Web-UI, in NVS persistiert; optional RFC2217 für dynamische Baudrate
• WLAN-Onboarding (Improv/Captive-Portal), Web-UI, OTA-Update, mDNS (cdc2net.local)

Roadmap: kabelgebundenes Ethernet (W5500) ist geplant — der Netz-Layer ist dafür schon abstrahiert.

Gesucht sind Tester mit echten Sticks: verschiedene CULs (V3/V4), TUL, EUL, nanoCUL sowie FTDI-/CH340-/CP210x-basierte Sticks. Interessant ist vor allem: Wird der Stick sauber erkannt (Enumeration im Log)? Läuft der FHEM-Dauerbetrieb stabil? Stimmt die Baudrate bei echten UART-Sticks?

Ausprobieren: Web-Flasher (Chromium-Browser) unter https://install.busware.de/cdc2net/ — geflasht wird das ESP32-S3-Board, nicht der Stick.
Quellcode (GPL) und Doku: https://github.com/tostmann/cdc2net
Rückmeldungen und Logs gern hier im Thread oder als GitHub-Issue.

Cheers!

[eisman]

hi,

muss zwar noch einen Adapter besorgen,

gehen auch HMLAN(HM-MOD-RPI-PCB), deConz 3

gruss

[tostmann]

Hallo eisman,

danke fürs Draufschauen! Bevor Du Geld für einen Adapter ausgibst, einmal kurz die Begriffe sortieren — denn für Deinen Fall ist CDC2NET vermutlich gar nicht das richtige Werkzeug, RFNETHM dagegen schon.

Was CDC2NET macht: Es ist ein reiner USB-Host→TCP-Bridge. Du steckst einen USB-Stick (CUL/TUL/EUL, oder per VCP-Treiber einen FTDI/CH340/CP210x-Dongle) in den USB-Host-Port des ESP32-S3, und CDC2NET macht daraus einen Netzwerk-Port (raw TCP bzw. RFC2217), den FHEM wie ein lokales Device anspricht. Es setzt also zwingend einen ESP32 mit USB-OTG-Host voraus und ,,versteht" das Protokoll des Sticks bewusst nicht — es schiebt nur Bytes.

HMLAN: Ein echter HM-LAN-Adapter (HM-CFG-LAN) ist bereits ein LAN-Gerät — der hängt von Haus aus am Netzwerk und wird in FHEM direkt über das HMLAN-Modul eingebunden. Da braucht es gar keine Bridge dazwischen. Wenn Du dagegen HomeMatic-/HmIP-Funk über das Netzwerk erreichbar machen willst, ohne einen teuren LAN-Configurator zu kaufen, ist das der eigentlich interessante Fall — und genau dafür gibt es ein eigenes Projekt:

Für HomeMatic → RFNETHM: https://github.com/tostmann/RFNETHM

RFNETHM hängt einen unmodifizierten HmIP-RFUSB-Stick (oder ein RPI-RF-MOD / HM-MOD-RPI-PCB am Pin-Header) ins Netzwerk und emuliert dabei ein HB-RF-ETH. Heißt: in RaspberryMatic / piVCCU taucht es mit einem Klick als Funkmodul auf, genau wie ein echtes HB-RF-ETH — und parallel bietet es einen HMUARTLGW-Port (TCP 2330) für FHEM CUL_HM und Homegear. Der Funk-Teil bleibt dabei der echte eq-3-Stick mit eq-3-Firmware, also alle BidCoS-/HmIP-Eigenheiten inkl. AES genau wie im Original. Flashen wieder bequem per Browser: https://install.busware.de/rfnethm/

Du brauchst also für HomeMatic keinen HMLAN, sondern einen RFUSB (oder ein HM-Modul) — und RFNETHM bringt den mit einem Klick in die CCU bzw. über TCP 2330 in FHEM.

deCONZ 3 / ConBee III: Das habe ich noch nicht getestet, deshalb hier ehrlich ohne Versprechen. Rein technisch ist der ConBee ein USB-Serial-Gerät und als Quelle für CDC2NET grundsätzlich denkbar — aber ob er sich als sauberes CDC-ACM meldet oder einen USB-Chip braucht, den ich noch nicht im VCP-Treibersatz habe, müsste ich erst mit dem Stick am Host messen. Und Achtung: deCONZ erwartet normalerweise ein lokales serielles Device; es über einen Netzwerk-Port zu betreiben (raw TCP / RFC2217 → virtuelles ttyUSB) ist machbar, aber nicht ,,ein Klick". Wenn Du einen ConBee III hast und Lust auf einen Test, sag Bescheid — dann schauen wir uns das konkret an.

Kurz: für HomeMatic → RFNETHM mit RFUSB/HM-Modul (HB-RF-ETH-Emulation, ein Klick in die CCU), für Zigbee/deCONZ → erstmal offen, gerne mit echter Hardware testen.

Gruß,
Dirk

[eisman]

hi,

den HM-MOD-RPI-PCB habe ich auch schon mit ESP8266/Serial betrieben,
aktuell laufen 2 über USB(FT232RL).
Da ich noch einen liegen habe, könnte ich den auch über CDC2Net ausprobieren.

bei dem deConz3 bin ich mir nicht sicher,
den deConz2 hatte ich auch schon über ser2net laufen.

beide Installationen liefen in einer Hyper/V(VM)

aktuell habe ich die Installationen auf ProxMox

da ich aktuell alles auf ESP32S3/R16N8 umstelle, habe ich natürlich auch 3stück als Reserve eingeplant.


grüß

[tostmann]

Hallo eisman,

sehr gut — Du bist für beides genau richtig ausgerüstet, und mit ser2net kennst Du den Anwendungsfall ja schon aus der Praxis. Lass uns die zwei Geräte kurz auseinandersortieren, dann weißt Du, was wohin gehört:

HM-MOD-RPI-PCB → das ist der klassische RFNETHM-Fall, nicht CDC2NET. RFNETHM nimmt das HM-MOD-RPI-PCB direkt auf den 40-Pin-Header des ESP32-S3 (also ohne den FT232RL davor) und stellt es dem Server dann auf zwei Wegen bereit: als HMUARTLGW-Port (TCP 2330) für FHEM CUL_HM / Homegear und parallel als HB-RF-ETH-Emulation für RaspberryMatic / piVCCU. Der Funk-Teil bleibt das echte eq-3-Modul mit eq-3-Firmware. (Wenn Du das Modul unbedingt am FT232RL lassen willst statt am Header, ist das ein reiner Raw-Serial-Bridge-Fall — das können wir separat anschauen, aber der Header-Weg über RFNETHM ist der sauberere.)

ConBee II → das ist der CDC2NET-Kandidat, also genau das, was Du heute mit ser2net machst. Ob CDC2NET ihn direkt öffnet, hängt an seinem USB-Chip — und da rate ich lieber nicht, sondern messe. Kannst Du mir kurz sagen, als was Dein ConBee II unter Linux auftaucht?

- erscheint er als /dev/ttyACM* (→ CDC-ACM, dann sollte CDC2NET ihn ohne Weiteres erkennen), oder als /dev/ttyUSB* (→ dann steckt ein USB-Serial-Chip dahinter)?
- und einmal die Zeile aus lsusb für den Stick (VID:PID + Hersteller)?

Damit kann ich Dir verbindlich sagen, ob der ConBee II direkt läuft oder ob ich seinen Chip erst in den VCP-Treibersatz aufnehmen muss — statt Dich blind probieren zu lassen.

Drei S3 in der Hinterhand klingt perfekt für einen direkten Vergleich CDC2NET vs. Dein bestehendes ser2net. Melde Dich mit der lsusb-Zeile, dann legen wir los.

Gruß,
Dirk