--- title: "Building the Client Controller for Access Control" url: "https://maker.wiznet.io/Alan/projects/building-the-client-controller-for-access-control/" markdown_url: "https://maker.wiznet.io/Alan/projects/building-the-client-controller-for-access-control/md" type: "UCC: User Created Content" author: "S Joy" author_url: "https://rockyroad.studio/2026/02/11/gate-project-building-the-client-controller-for-access-control/" editor: "WIZnet" editor_url: "https://maker.wiznet.io/" original_author: "S Joy" original_url: "https://rockyroad.studio/2026/02/11/gate-project-building-the-client-controller-for-access-control/" published: "2026-10-12" language: "en" likes: 0 views: 7 comments: 0 source: "WIZnet Makers (https://maker.wiznet.io/)" --- # Building the Client Controller for Access Control > Building the Client Controller for Access Control Original author: S Joy (source: https://rockyroad.studio/2026/02/11/gate-project-building-the-client-controller-for-access-control/) ## Article ## Overview ![](https://maker.wiznet.io/upload/ckeditor5/f27b3450d29e4745a008e9df625ff360.jpg) The **Gate Project** is an access control prototype developed by **Rocky Road Studio**. The project uses multiple client devices that communicate with a server to perform access control. In the prototype stage, the client controller is used as a **door access control device**. When access is granted, the controller triggers a relay to control a magnetic door latch. The hardware is built around: - ESP32 WROOM-32UE main controller - W5500 Ethernet module for wired networking - TFT monitor module for user interface - MFRC522 RFID controller for card-based access - Relay circuit for magnetic door latch control - Buzzer for feedback signals - Reserved fingerprint sensor port for future biometric integration This makes the Gate Project a practical example of an access control client where **W5500-based Ethernet I/O module design** is used to add reliable wired networking to a door controller. --- ## What Problem Does This Controller Solve? ![](https://maker.wiznet.io/upload/ckeditor5/26e1d71d62b340709d0e4b1e8dd8bd48.jpg) Access control systems need to identify users, communicate with a backend system, and control physical door hardware. A typical door controller must handle: - Card reading - User feedback - Server communication - Door latch control - Device configuration - Network setup - Future expansion for additional authentication methods In the Gate Project, the controller reads RFID card data, sends an access request to a server, receives an approval or rejection response, and then controls the door latch through a relay. The project originally used UDP JSON dumps for client-server communication, but later moved to REST APIs to make the communication structure more standardized and reliable. This turns the controller into both: - An API client that sends metadata and access requests to the server - An API server that hosts a local configuration webpage for administrators --- ## How Is the Hardware Structured? The controller is designed as a modular embedded access control device. The ESP32 WROOM-32UE acts as the main controller. The W5500 module provides wired Ethernet connectivity. The MFRC522 RFID controller handles card-based access input. The relay circuit controls the magnetic door latch. The TFT display and buzzer provide user feedback. The reserved fingerprint sensor port leaves room for future biometric authentication. The basic structure can be described as follows: ```plaintext RFID Card | | MFRC522 RFID Reader | ESP32 WROOM-32UE Client Controller | | SPI / Ethernet Interface | W5500 Ethernet Module | | Wired Network | Access Control Server | | Access Granted / Denied | Relay Circuit | | Magnetic Door Latch ``` This design separates the controller into four key functions: - Access input through RFID - Local control through ESP32 - Network communication through W5500 - Physical door control through relay output --- ## What Does W5500 Add to the Gate Controller? W5500 provides the wired Ethernet connection for the access control client. In an access control system, network reliability matters because the device must communicate with the server whenever a user attempts access. ### Reliable Wired Networking The ESP32 WROOM-32UE was selected partly because it supports an external Wi-Fi antenna, helping improve wireless signal strength. However, wired Ethernet is still valuable for access control installations because doors, gates, and building control points often require stable communication. The W5500 module gives the controller a wired network option for more reliable server communication. ### Ethernet I/O Module Design The project uses W5500 as the Ethernet networking block inside a modular access control controller. This is important because the device is not just a basic Ethernet demo. W5500 is part of a complete I/O controller that also includes RFID input, display output, buzzer feedback, relay control, and future fingerprint sensor expansion. ### Better Fit for Fixed Installations Access control clients are usually installed in fixed locations. For these installations, wired Ethernet can be preferred because it avoids Wi-Fi coverage issues, interference, and reconnection problems. W5500 helps make the client controller suitable for fixed building and facility access control deployments. ### Practical Embedded Ethernet W5500 provides a practical way to add Ethernet to an ESP32-based controller. The ESP32 handles application logic, web configuration, RFID processing, encryption, and relay control. W5500 handles the wired Ethernet interface. This division helps keep the hardware structure modular and easier to expand. --- ## Why Is REST API Communication Used? The project originally used UDP JSON dumps between the client and server. That approach worked, but the project moved toward REST APIs to use a more standardized communication method. With REST APIs, the ESP32 acts as both a client and a server. As an API client, it sends metadata and access requests to the backend server. As an API server, it hosts a local configuration webpage that administrators can open through the device IP address. This improves the structure of the project because communication becomes more organized and easier to extend. --- ## How Does the Access Flow Work? The access control process can be described as follows: - On startup, the client sends metadata to the server - If the device is registered in the database, the server returns a unique identifier - This identifier is used to validate later communication - When an RFID card is presented, the client sends card data to the server - The server checks the database and returns access granted or denied - If access is granted, the controller triggers the relay - The relay controls the magnetic door latch This flow allows the server to own the access decision while the client controller handles local input and physical output. --- ## How Is the Local Web Interface Used? The ESP32 hosts a local webpage at its IP address. Administrators can use this page to configure the access control client. The configuration page can be used to set: - Room name - Access type such as entrance or exit - Wi-Fi SSID and password - Fixed IP address To prevent anonymous configuration access, the project adds a login page with token-based authentication. The token refreshes every 30 minutes. Only one admin session is allowed at a time. This approach is simple but practical for a prototype, because only one administrator should be configuring the device at once. --- ## How Is Security Handled? The project recognizes that HTTPS would be necessary for enterprise-grade security. However, HTTPS can be difficult in this environment because it requires a fixed domain rather than only floating IP addresses. A local DNS server would be required to assign a valid domain name. For the prototype stage, the project uses **AES encryption** as a practical compromise. This is a reasonable engineering tradeoff during development, especially when balancing embedded limitations, security needs, and deployment complexity. --- ## Why Was SPIFFS Used Instead of an SD Card? The project initially considered using the TFT module’s SD card for data logging and logo customization. However, SD cards can wear out over time and add extra handling complexity. The project switched to SPIFFS, the SPI Flash File System embedded in the ESP32. This made storage faster, simpler, and more reliable for the project. Because both SD and SPIFFS are file system objects in the code structure, the migration was relatively simple. SPIFFS is used for items such as configuration data, logs, and small logo storage. --- ## How Were ESP32 Storage Limits Solved? During development, the firmware became large. The program used AsyncWebServer, TFT_eSPI, MFRC522PlusExtended, Ethernet.h, and other libraries. The compiler showed that the sketch was using about 95% of the default program storage space. To solve this, the project changed the ESP32 partition scheme. The default partition had less application space and more SPIFFS space. By switching to a **Minimal SPIFFS** partition, the application space increased from about 1.2 MB to about 1.9 MB. This reduced program usage to about 63%, leaving more room for future functions such as fingerprint sensor integration. --- ## System Architecture The complete system can be divided into several layers. ```plaintext Authentication Layer --------------------------------- RFID card MFRC522 RFID controller Reserved fingerprint sensor port User Interface Layer --------------------------------- TFT monitor module Buzzer feedback Local configuration webpage Control Layer --------------------------------- ESP32 WROOM-32UE REST API client Local API server AES encryption SPIFFS storage Network Layer --------------------------------- W5500 Ethernet module Wi-Fi with external antenna option Fixed IP configuration Server communication Output Layer --------------------------------- Relay circuit Magnetic door latch control Access granted / denied response ``` This layered structure shows how the Gate Project combines authentication, networking, web configuration, and physical door control. The RFID reader provides the user input. The ESP32 handles logic and configuration. The W5500 provides wired Ethernet networking. The relay circuit controls the magnetic door latch. --- ## What Applications Can Use This Design? This access control controller architecture can be used in many applications. Possible applications include: - Door access control - Gate access control - Room entry management - Office access systems - Equipment access control - Computer access control - Facility access monitoring - RFID-based authentication devices - Network-connected relay controllers - Ethernet-connected I/O modules - Building security systems - Prototype access control platforms The same structure can also be expanded with fingerprint authentication or other sensor inputs. --- ## Why Is This a Good W5500 Use Case? The Gate Project is a good W5500 use case because Ethernet is used as part of a complete access control I/O module. The W5500 is not used only for a basic network test. It supports a real embedded control device that includes RFID input, local UI, server communication, relay output, and future biometric expansion. W5500 helps the system: - Add wired Ethernet to an ESP32 access controller - Improve reliability for fixed access control installations - Connect the client controller to a backend server - Support REST API-based communication - Fit into a modular I/O controller design - Work alongside RFID, display, buzzer, and relay circuits - Enable a practical network-connected door control prototype This makes W5500 an important part of the Gate Project’s client controller architecture. --- ## Conclusion The Gate Project shows how **ESP32 WROOM-32UE** and **WIZnet W5500** can be used to build a network-connected access control client. The controller reads RFID card data, communicates with a server through REST APIs, hosts a local configuration webpage, and controls a magnetic door latch through a relay circuit. W5500 provides the wired Ethernet networking option for the controller, making the design more suitable for fixed installations where reliable server communication is important. The project also shows several practical embedded engineering decisions, including the move from UDP JSON dumps to REST APIs, token-based web configuration, AES encryption, SPIFFS storage, and ESP32 partition optimization. Overall, this is a strong example of W5500 being used inside a real access control I/O module, where Ethernet communication, authentication input, and physical relay control all work together. --- ## Q&A ### What is the Gate Project? The Gate Project is an access control prototype where multiple client controllers communicate with a server to manage door access. ### Which WIZnet product is used? The project uses a **W5500 Ethernet module** for wired networking. ### What is the main controller? The main controller is **ESP32 WROOM-32UE**. ### What is the role of W5500? W5500 provides wired Ethernet connectivity between the client controller and the access control server. ### What authentication method is used? The prototype uses an **MFRC522 RFID controller** for card-based access. ### What does the relay control? The relay controls a magnetic door latch for access control. ### Why did the project move from UDP to REST APIs? REST APIs provide a more standardized and reliable structure for client-server communication. ### How is the device configured? The ESP32 hosts a local configuration webpage where administrators can configure room name, access type, Wi-Fi settings, and fixed IP address. ### How is configuration access protected? The project uses token-based authentication, 30-minute token refresh, and one active admin session at a time. ### Why is SPIFFS used? SPIFFS is used instead of an SD card because it is embedded in ESP32 flash, faster, simpler, and more reliable for this type of configuration and storage use. ### What applications can use this architecture? This architecture can be used for door access control, gate control, facility access systems, RFID authentication, network-connected relay controllers, and Ethernet-based I/O modules. --- Source: https://maker.wiznet.io/Alan/projects/building-the-client-controller-for-access-control/