IP4KNX IP4KNX

Turns a TUL into a full KNXnet/IP gateway — routing and up to ten simultaneous tunnels, with a web dashboard and no knxd anywhere in the picture.

Version v1.4.14  runs on: TUL, TUL32

A KNXnet/IP gateway that fits on a USB stick: routing and tunnelling, a web dashboard, and no knxd between you and the bus. It is built on the OpenKNX stack, patched for the NCN5130 transceiver the TUL carries.

Home Assistant finds it by itself through KNXnet/IP routing. ETS, Node-RED and anything else that speaks the protocol can be connected at the same time — the gateway holds up to ten concurrent tunnels.

Features

• Ten tunnels at once. Each connection gets its own individual address, and a frame arriving with a foreign source address is rewritten before it reaches the bus — the behaviour KNXnet/IP Core §4.4 prescribes, and what keeps one tunnel client from impersonating another.
• Optional wired Ethernet on the TUL32. A W5500 module on the FPC header is detected at boot, so one build covers a populated and an unpopulated board. Once the cable has a link and a lease, the Wi-Fi radio is parked and the gateway holds exactly one address on the network; pull the cable and the radio comes back. Routing follows the active interface and re-joins its multicast group.
• Setup without a toolchain. With no credentials stored, the stick opens its own access point and a captive portal takes you straight to the dashboard; alternatively Wi-Fi can be handed over from the browser over Improv during the first two minutes after boot. Holding the button for two seconds forces the access point back at any time.
• Updates that cannot brick it. Two app partitions with bootloader rollback: a freshly written partition stays on probation for 30 seconds, and firmware that crashes before that is replaced by its predecessor at the next boot. Updates come either from the signed manifest over HTTPS or as a manual upload, both verified by checksum.
• It checks its own hardware. Every boot verifies the link to the NCN5130, its power rails, crystal and thermal status — visible on the dashboard and in the status API.
• Programming mode from the dashboard, so commissioning with ETS does not mean reaching for the physical button.
• A dashboard worth opening: uptime, network details, active tunnel slots, transceiver state, OTA partition and live bus statistics. Reachable at http://tul.local, and both interfaces announce a DHCP hostname carrying the stick’s own suffix, so it is recognisable in the router’s lease list.
• Hardened where it faces the network. State-changing HTTP endpoints reject requests whose origin does not match the host, the onboarding access point serves onboarding only, and inbound frames are validated against malformed and truncated cEMI before anything reaches the bus.

Requirements

• A TUL — either generation: the ESP32-C3 board or the current TUL32 with the ESP32-C6. Wired Ethernet is available on the TUL32 only; the older board has no header for it.
• A KNX installation, and a client that speaks KNXnet/IP — Home Assistant, ETS, Node-RED, FHEM.

Getting started

Flash it in the browser at install.busware.de/ip4knx/ — Chrome, Edge or Opera. The page detects the board, writes the factory image and hands over Wi-Fi credentials in one flow. After that the gateway announces itself over mDNS and Home Assistant discovers it without further configuration.

FHEM talks to it directly through its KNXIO module, no knxd in between — the HowTo covers both tunnelling and routing mode.

Limits

The firmware is specific to the TUL hardware: the pin assignment and the NCN5130 handling differ per board, which is why the flasher writes the image matching the stick it finds rather than offering a generic download.