Wiznet makers

Replacing a Proprietary Smart Building Hub with ESP32 + W5500 — An Open Gateway for IPBuilding

Overview

Every smart building needs a brain. For over 2,000 homes, apartments, and offices across Belgium, that brain is the IPBox — a proprietary hub by IPBuilding NV that controls lighting relays, dimmers, motorized blinds, and access control across a real commercial building automation system.

The IPBox works. But it is aging, expensive to replace, and completely closed. When it crashes, the building loses control. When a user wants Home Assistant or MQTT, the answer is no.

This project replaces it with an ESP32 + W5500 PoE board — a protocol-compatible open gateway that speaks the same UDP/1001 fieldbus, discovers PoE Ethernet field modules over ARP, and exposes a WebSocket and REST API that Home Assistant, MQTT, and Matter can connect to directly. Powered entirely by the Ethernet cable already in the wall.

IPBuilding — A Real Commercial Smart Building Solution

https://www.ipbuilding.be/

IPBuilding NV is a Belgian company specializing in Smart Home, Smart Building, and Smart Care solutions, with over 2,000 intelligent systems already installed across private homes, apartments, assisted-living residences, care homes, offices, and retail spaces. Tycosp

The platform integrates lighting, heating, ventilation, motorized blinds, access control, IP cameras, energy monitoring, and multi-room audio into a single app, with documented energy savings of up to 30%.

The field control layer consists of three PoE Ethernet field modules:

Module	Role	Fixed IP
IP0200PoE	24-channel relay (lighting, outlets)	10.10.1.30
IP0300PoE	8-channel dimmer (0–100% brightness)	10.10.1.40
IP1100PoE	Pushbutton input module	10.10.1.50

The Problem: A Proprietary Hub Called IPBox

All three field modules are centrally managed by the IPBox (IP0000X) — a dedicated controller with two physical Ethernet ports. One port connects to the home LAN to serve the REST API (TCP port 30200) and web interface; the other connects to the IPBuilding-dedicated VLAN (10.10.1.x) to handle UDP/1001 fieldbus communication with the field modules. It runs on a 12V DC adapter and bundles the IPBuilding service, web server, REST API, music server, remote access server (Radmin, port 4899), and DNS server all in one box.

The functionality is solid. The problem is the IPBox's structural limitations.

Single Point of Failure
The IPBox is the sole bottleneck that proxies both fieldbus and user interface traffic. Its single-process architecture means the service software halts whenever the diagnostic tool (IP-diagnostic) is open — if the box goes down, the entire building loses control.

Closed Ecosystem Lock-in
While a REST API exists on port 30200, all scene and automation logic is stored exclusively inside the IPBox with no way for users to modify it directly or integrate with open platforms like Home Assistant, MQTT, or Matter. 

Aging Hardware, Risk of Failure
The project documentation explicitly describes the IPBox as "outdated, expensive, and vulnerable (verouderd, duur, kwetsbaar)" and marks it as the top replacement priority. In at least one real installation, the IPBox was already at risk of crashing with no affordable replacement path. 

Physical Placement Constraints
For energy monitoring (HEMS), the smart meter's P1 port must be connected directly to the IPBox USB port, with a cable length limit of 1.5 meters — meaning the IPBox must always be installed physically next to the smart meter. Depending on the building layout, this severely limits installation flexibility. 

The Solution: ESP32 + W5500 Replaces the IPBox

IPBuilding-Gateway is the open-source gateway that solves all of these problems. And in this project, the ESP32 + W5500 combination is not just a connectivity component — it is the core of the solution itself.

W5500 — Speaking the Same Physical Layer as the Field Modules

IPBuilding's three field modules (IP0200PoE, IP0300PoE, IP1100PoE) are all PoE Ethernet devices. They communicate with the hub over the 10.10.1.x subnet using a binary ASCII protocol on UDP port 1001. 

The W5500 implements the exact same 10/100 Ethernet physical layer as these modules. This means thousands of already-deployed commercial field modules can talk to the W5500-based gateway in exactly the same way they talked to the IPBox — no protocol changes, no firmware modifications on the modules.

The W5500 performs three concrete roles in this project:

① Direct UDP/1001 Fieldbus Control
Relay ON/OFF commands (S{ch}00 / C{ch}00), dimmer brightness control (S{ch}{val}1030, 0–100%), and button event reception (B-...E packets) are all handled directly through the W5500. Poll intervals mirror the IPBox: approximately 2 seconds for input modules and 20 seconds for relay and dimmer modules. 

② ARP-Based Automatic Device Discovery
The gateway reads /proc/net/arp directly to filter for IPBuilding's proprietary OUI 00:24:77, scanning the entire 10.10.1.0/24 subnet in approximately 20 seconds to auto-detect relay, dimmer, and input modules. The IPBox's own OUI (00:30:18) is explicitly excluded from discovery. Because the W5500 is connected to the same subnet, this ARP-based detection works reliably without any additional configuration. 

③ Per-Module HTTP Configuration Access
For each discovered module, the gateway accesses the embedded HTTP api.html interface to read getSysSet (system settings and firmware version), backupConfig (channel labels and room assignments), and getButtons (IP1100PoE button configuration), all of which are persisted to devices.json. This is what allows Home Assistant to automatically populate accurate room names and channel labels without any manual setup. 

ESP32 — A Fully Standalone Embedded Gateway

The current primary deployment runs as a Python/Docker-based Home Assistant add-on or standalone container on a Raspberry Pi. The ESP32 firmware (C++/ESP-IDF) is on the next phase of the roadmap. 

But when this deployment form is complete, the implications are significant.

The ESP32 + W5500 firmware implements the same northbound protocol (WebSocket /ws, REST /api/v1/) as the Python implementation, so the companion integration and all clients work transparently. The same ARP discovery algorithm applies, using lwIP's etharp_query() — no arp-scan or mDNS required to detect IPBuilding modules on the fieldbus segment. 

The result: no Linux server, no Raspberry Pi, no 12V power adapter. A single ESP32 + W5500 PoE board plugged directly into the 10.10.1.x fieldbus segment becomes a permanent gateway that bridges a commercial building automation system — deployed across 2,000+ real buildings — into the open Home Assistant, MQTT, and Matter ecosystem. PoE powers the board directly over the Ethernet cable, eliminating the need for a separate power supply entirely.

Every physical placement constraint of the IPBox disappears: no mandatory proximity to the smart meter, no dedicated rack space, no 12V adapter.

How It Works

The gateway is organized into two protocol layers.

Southbound Layer — Fieldbus
The W5500 sends and receives UDP/1001 packets directly to and from field modules on 10.10.1.x.
Relay commands use the format S{channel:02d}00 (ON) and C{channel:02d}00 (OFF). Dimmer commands use S{ch}{val}1030 for absolute brightness, T{ch}991000 for toggle, and D{ch}001003 / D{ch}001000 for hold-dim start and stop. Button events arrive as 14-byte B-...E packets carrying press (01) and release (00) edges.

Long press detection follows the same logic as the IPBox: the IP1100PoE only transmits press and release edges over the fieldbus. The gateway measures the time between press and release and compares it against a configurable threshold (0.5 to 5 seconds) to distinguish a short press from a long press — no additional fieldbus decoding required. 

Northbound Layer — Client API
Port 8080 exposes WebSocket (/ws) and REST (/api/v1/). Event types include state_changed, button_event, snapshot, device_added, device_removed, device_ip_changed, and device_firmware_changed. Clients send command messages (ON/OFF/DIM) and discover to trigger on-demand module scanning.

EEPROM Autonomous Operation
Button-to-relay mappings are written directly to the IP1100PoE module's EEPROM — the same autonomy mechanism the IPBox uses. While the gateway is online, the IP1100PoE runs in slave mode (LED solid green). If the gateway goes offline, it switches to autonomous mode (LED blinking green) and executes lighting control independently based on the stored EEPROM mapping. The building does not go dark when the gateway restarts.

IPBox vs. Open Gateway

Deployment Options

When using Home Assistant, installing the companion HACS integration (ha-ipbuilding-gateway) alongside the gateway automatically registers lights, switches, sensors, and button entities in HA — ready for dashboards and automations with no manual entity configuration.

Future roadmap includes a MQTT adapter, a Matter bridge for Apple Home and Google Home, and the ESP32 firmware as a fully self-contained embedded deployment.

Project Status

Actively developed with 18 releases and 192 commits through v1.6.0 (July 16, 2026), which added global double and triple press support.

• Gateway repository: github.com/markminnoye/IPBuilding-Gateway
• HA companion integration: github.com/markminnoye/ha-ipbuilding-gateway
• IPBuilding official site: ipbuilding.be