MacroPark was my 2024 graduation project at Scheidt & Bachmann Maghreb, delivered across five Scrum sprints. I engineered and validated its administration, Flutter access, LPR/MQTT, and embedded barrier-control workflows. Administrators manage users, guests, access evidence, barriers, emergency commands, and event logs; drivers enter through camera-based plate recognition or the mobile app over BLE; and WT32-ETH01 firmware controls four barrier channels with persistent configuration and OTA maintenance.
Graduation project at Scheidt & Bachmann02 /Product experience
What the product does.
01Parking Supervision4 capabilities
Administration Platform
A central dashboard connects user, guest, entry-history, barrier, emergency-control, and barrier-event modules.
Every access record can include user, method, device, time, recognized plate, and captured LPR evidence.
Barrier Operations
Installed barriers, individual command channels, emergency actions, and controller event logs are managed from the web platform.
02Driver Access2 capabilities
Camera-Based Entry
A Quercus SmartLPR camera captures plates, passes them through Bridge and Core services, and triggers an approved barrier command.
Flutter BLE Entry
Authenticated drivers can request barrier access from the Android app, then review their profile and camera or phone access history.
03Edge Controller3 capabilities
Four-Barrier Firmware
The WT32 firmware drives four independent open/close relay pairs and supports timed automatic closing for mobile commands.
Provisioning & Persistence
A local configuration portal manages IP and MQTT settings; SPIFFS preserves network and company-ID configuration across restarts.
OTA Maintenance
Arduino OTA handlers and the controller web portal provide a practical remote firmware-update workflow.
04Delivery1 capabilities
Containerized Service Stack
Docker Compose starts the Backend, Core, LPR/Bridge, and Mosquitto services together with explicit ports and topics.
03 /System design
How the pieces connect.
System workflow
MacroPark access and control ecosystem
Camera and mobile access paths converge on the same services, controller, physical barriers, and traceable operating history.
Camera access path
Vehicle detection
Quercus SmartLPRCaptures and recognizes the license plate
LPR event
Service decision
Bridge serverReceives the camera event
Core serverCoordinates verification and MQTT flow
Backend serverChecks users, plates and permissions
MQTT command
Physical access
WT32-ETH01Validates the command and drives relays
BarrierOpens, closes and reports controller state
Mobile access path
Driver application
Flutter appAuthentication, access request and history
BLE command
Edge validation
WT32 BLE scannerChecks the configured company identifier
Controller firmwareMaps the request to a barrier channel
Relay action
Recorded access
Physical barrierExecutes the open and timed-close sequence
MQTT eventReports the action for operational history
01Two Access Paths, One Parking System
MacroPark is the complete product. Its architecture map shows how the admin platform, mobile app, Quercus camera, Bridge server, Core server, Backend server, databases, Mosquitto broker, WT32 controller, and physical barrier work together.
The LPR camera sends a plate event through Bridge and Core services for backend verification before an MQTT barrier command.
Mobile path
The Flutter app authenticates through the backend and broadcasts a BLE command that the WT32 validates and records through MQTT.
Operations path
The admin interface manages records and emergency commands while access and controller actions remain traceable.
02WT32 Edge-Control Boundary
The WT32-ETH01 connects network communication to physical relay outputs. The supplied 566-line firmware covers Ethernet and Wi-Fi setup, MQTT subscriptions, BLE scanning, four barrier channels, timed closing, SPIFFS configuration, reset behavior, and OTA updates.
The working system required three application servers, an MQTT broker, databases, a camera, a mobile client, and an embedded controller to agree on access decisions and logs.
02
Two Access Paths, Consistent Control
Camera/MQTT and phone/BLE entry had to converge on the same physical barrier behavior while preserving the source and evidence for each event.
03
Reliable Edge Configuration
The controller needed to remain configurable when infrastructure changed, persist critical network and company settings, and expose a reset path.
04
From Software to Physical Validation
Relay wiring, four control channels, timed closing, permissions, BLE payloads, MQTT topics, and actual barrier responses were tested as one system.
06 /The toolkit
Each tool has a job.
Open a technology to see its role in this project.
Product Applications
Admin platform +
FastAPI and Jinja interface for parking supervision
Flutter +
Android access, profile, guest registration, and history flows
REST + Swagger +
Documented APIs shared across product components
Services & Data
FastAPI +
Backend, Core, and LPR/Bridge service workflows
Mosquitto MQTT +
Camera, decision, controller, and audit messaging
MongoDB + SQLite +
Application and local service persistence
Docker Compose +
Coordinated deployment of three servers and the MQTT broker
Embedded Controller
C++ / Arduino +
WT32-ETH01 barrier-control firmware
Ethernet + Wi-Fi +
Wired operation with an access-point configuration path
BLE +
Proximity access commands from the mobile application
SPIFFS + OTA +
Persistent configuration and remote firmware maintenance
Vision & Hardware
Quercus SmartLPR +
Camera-based vehicle plate capture and recognition
WT32-ETH01 +
Networked edge controller for barrier commands
Four relay channels +
Independent open and close outputs for four barriers
07 /Delivery notes
The documented scope.
Four Integrated Product Layers
Admin web, Flutter mobile, LPR services, and embedded barrier control form one complete parking product.
Two Verified Entry Methods
The presentation and report document successful camera/MQTT and mobile/BLE barrier-opening paths.
Five-Sprint Delivery
Implementation progressed through platform, mobile, controller, LPR, and test-and-validation sprints.
Hardware-Backed Prototype
Controller configuration, relays, BLE events, MQTT commands, OTA behavior, and access history were validated beyond static interface mockups.
Explore further
Want to go deeper?
Explore the available resources or talk with me about the design and engineering behind this project.
Quercus SmartLPRCaptures and recognizes the license plate
WT32-ETH01Validates the command and drives relays
Flutter appAuthentication, access request and history
Controller firmwareMaps the request to a barrier channel
MQTT eventReports the action for operational history
