Project Architecture Overview
Esta página aún no está disponible en tu idioma.
Project Architecture Overview
Overview
Section titled “Overview”This section introduces the Asset Tracking project, which uses RFID technology combined with an ESP32 microcontroller to create a check-in/check-out system for personnel and asset management. Learning this section will enable you to:
- Understand the overall architecture of the RFID-based tracking system
- Identify the key hardware and software components involved
- Describe the data flow from RFID scan to database recording
- Recognize the buyer scenarios this project addresses on Alibaba.com
Prerequisites
Section titled “Prerequisites”Before starting this section, ensure you are familiar with:
- Basic ESP32 capabilities (see Chapter 01)
- MQTT protocol fundamentals (see Chapter 06)
- Node-RED basic concepts (see Chapter 09)
- Docker container basics (see Chapter 07)
Alibaba.com Buyer Scenario
Section titled “Alibaba.com Buyer Scenario”Target Buyer
Section titled “Target Buyer”International buyers on Alibaba.com who need:
- Factory attendance tracking: Record employee check-in/check-out times
- Tool and asset management: Track借用/归还 of equipment, tools, or assets
- Inventory entry/exit recording: Log items entering or leaving a warehouse
- Work order tracking: Associate worker time with specific production orders
Buyer Pain Points
Section titled “Buyer Pain Points”| Pain Point | How This Solution Addresses |
|---|---|
| Manual time tracking is error-prone | RFID scan provides automated, accurate recording |
| Paper-based records are hard to analyze | Digital records enable reporting and analytics |
| Tool loss due to poor tracking | Each scan logs who has which asset and when |
| Difficult to calculate labor costs | Time entries are automatically linked to projects |
System Architecture
Section titled “System Architecture”High-Level Overview
Section titled “High-Level Overview”┌─────────────────────────────────────────────────────────┐│ Asset Tracking System │├─────────────────────────────────────────────────────────┤│ ││ [RFID Tags] ──→ [RC522 Reader] ──→ [ESP32] ││ ↑ │ ││ │ │ MQTT/HTTP ││ │ ↓ ││ │ [WiFi Network] ││ │ │ ││ │ │ ││ ┌────┴────────────────────────────────────┴──────┐ ││ │ Server Stack (Docker) │ ││ │ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ ││ │ │ TimeTagger│ │ Node-RED │ │ Database │ │ ││ │ │ (REST API)│←─│ (Flow) │←─│ (JSON File) │ │ ││ │ └──────────┘ └──────────┘ └──────────────┘ │ ││ └────────────────────────────────────────────────┘ │└─────────────────────────────────────────────────────────┘Component Breakdown
Section titled “Component Breakdown”| Component | Role | Technical Notes |
|---|---|---|
| RFID Tags | Unique identifiers for personnel/assets | Passive tags, 13.56MHz (HF), no battery needed |
| RC522 Reader | Reads RFID tag UID | SPI interface, 3.3V only, ~3-5cm read range |
| ESP32 | Main controller | WiFi + MQTT, reads tag, controls LEDs |
| TimeTagger | Time tracking software | Open source, REST API, Docker container |
| Node-RED | Flow automation | Orchestrates MQTT/HTTP communication |
| File-based storage | Local check-in state | JSON flat file on server |
Data Flow
Section titled “Data Flow”Check-In Flow
Section titled “Check-In Flow”1. User taps RFID tag on reader2. ESP32 reads tag UID via RC522 (SPI)3. ESP32 publishes UID to MQTT topic4. Node-RED receives MQTT message5. Node-RED checks if check-in file exists on server6. If file does NOT exist → This is a CHECK-IN7. Node-RED creates JSON file with start timestamp8. ESP32 turns on GREEN LED to indicate successCheck-Out Flow
Section titled “Check-Out Flow”1. Same user taps RFID tag again2. ESP32 reads same UID via RC5223. ESP32 publishes UID to MQTT topic4. Node-RED receives MQTT message5. Node-RED checks if check-in file exists6. If file EXISTS → This is a CHECK-OUT7. Node-RED reads the file, adds end timestamp8. Node-RED sends complete record to TimeTagger API via HTTP POST9. Node-RED deletes the local file10. ESP32 turns on RED LED to indicate completionState Machine
Section titled “State Machine” ┌──────────┐ │ IDLE │ │ (Waiting)│ └────┬─────┘ │ ┌──────▼──────┐ │ Tag Detected │ └──────┬──────┘ │ ┌──────▼──────┐ NO │ File Exists?│ YES ┌────────┤ on Server ├────────┐ │ └─────────────┘ │ ▼ ▼┌──────────┐ ┌──────────┐│ CHECK-IN │ │ CHECK-OUT││ Create │ │ Read File││ JSON File│ │ POST API │└────┬─────┘ │ Delete │ │ │ File │ │ └────┬─────┘ │ │ └──────────┬─────────────────┘ ▼ ┌──────────┐ │ DONE │ │ (LED FB) │ └──────────┘Key Technical Decisions
Section titled “Key Technical Decisions”| Decision | Choice | Rationale |
|---|---|---|
| RFID Frequency | 13.56 MHz (HF) | Good balance of read range and tag cost; works for proximity tracking |
| Reader Module | RC522 | Widely available, low cost (~$2), Arduino library support |
| Data Storage | Flat file on server | Simple, no database dependency; TimeTagger as final record |
| Server Communication | MQTT + HTTP | MQTT for real-time events; HTTP REST for TimeTagger API |
| State Persistence | JSON file Node-RED | Survives server restarts; easy to inspect and debug |
Project Sections Overview
Section titled “Project Sections Overview”This chapter is organized into the following sections:
| Section | Topic | Focus |
|---|---|---|
| 05-02 | RFID Reader Hardware Setup | Wiring the RC522 module to ESP32 |
| 05-03 | RC522 Module Integration | Library setup and SPI configuration |
| 05-04 | RFID Tag UID Reading | Reading and validating tag identifiers |
| 05-05 | TimeTagger Open Source Software | Installing and configuring TimeTagger |
| 05-06 | REST API Authentication | Obtaining and using API tokens |
| 05-07 | HTTP POST Request Implementation | Building and sending POST requests |
| 05-08 | Check-In API Integration | Full check-in/check-out flow |
| 05-09 | State Management Logic | File-based state tracking |
| 05-10 | LED Status Indicators | Visual feedback for operations |
| 05-11 | Technical Capability Assessment | Evaluating solution boundaries |
| 05-12 | Customization Possibilities | Adapting to different buyer needs |
Verification
Section titled “Verification”After completing this chapter, you should be able to:
- Explain the complete check-in/check-out flow to a buyer
- Identify the role of each component in the architecture
- Describe how RFID-based tracking solves factory attendance requirements
- Understand the difference between check-in and check-out state management
Summary
Section titled “Summary”Key takeaways:
- System architecture: RFID tags → RC522 → ESP32 → MQTT → Node-RED → TimeTagger
- Two-phase flow: Check-in (create file) and Check-out (send to API + delete file)
- State management: File existence on server determines check-in vs check-out behavior
- Buyer alignment: Solves factory attendance, tool tracking, and asset management needs
References
Section titled “References”Writing Date: 2026-05-17
Based on Source File: 校正版/10 Time recording witht RFID und TimeTagger.md
Target Audience: Alibaba.com IoT Pre-sales Engineer
Status: ✅ Completed
We provide ESP32 ODM design-to-manufacturing services. From prototype to production — the team behind this tutorial can build it with you.
Talk to us →