So we built one from scratch.

We started with the nRF52840 as the main application processor. It gave us Bluetooth 5.2 for local connectivity, enough GPIO pins to handle the motor drivers and sensors, and the ARM Cortex-M4F core could run our firmware without breaking a sweat. For Wi-Fi connectivity — because offices don't always have reliable BLE range — we paired it with an ESP32-S3 handling the network stack and OTA updates.

The PCB design went through four revisions in KiCad. First rev was a standard two-layer board. By rev three, we'd moved to four layers to separate the analog sensor lines from the digital noise. The motor controller section got its own ground plane after we saw noise spikes corrupting temperature readings from the cooling unit.

Our firmware team built on Zephyr RTOS. Here's why: Zephyr's native support for both the nRF52 and ESP32 families meant we could use the same codebase across both processors. The application layer ran on the nRF52840 — handling product detection, payment verification, and motor control. The ESP32 handled all network communication, MQTT messaging to the cloud backend, and managed the HTTPS connections for payment gateways.

- Sensor thread: Polls the weight sensors and infrared break beams every 50ms. Detects when a product is picked and when it's actually removed from the coil.

- Payment thread: Handles the payment flow — NFC tap, card insertion, or mobile app QR scan. Runs independently so users can start payment while the machine finishes a previous vend.

- Inventory thread: Updates the cloud database every time a product is vended. Also runs a daily reconciliation routine at 2 AM to compare physical stock against the database.

The trickiest part was the product detection logic. Weight sensors alone aren't reliable — a bag of chips weighs differently than a candy bar, and humidity changes throw off the readings. We ended up combining weight sensors with optical break beams at each coil position. The firmware cross-references both inputs and only confirms a vend when both sensors agree within a 200ms window.

The client wanted this specifically as a smart vending machine for office deployment. That meant several requirements that consumer vending machines don't typically handle:

Access control integration. The machine had to recognize employees through their existing office badge system. We added an NXP PN532 NFC reader that could read both Mifare Classic and DESFire cards. The firmware sends the badge ID to the cloud backend, which checks against the office directory and returns the employee's prepaid balance or billing account.

Inventory visibility. Office managers wanted to see stock levels in real time — not just "cola is low" but exactly how many units of each SKU remained. Our MQTT broker publishes inventory updates every time a product is vended, plus a full sync every hour. The cloud dashboard shows stock levels, predicts restock dates based on consumption patterns, and can send automated reorder requests to suppliers.

Temperature monitoring. The refrigerated section needed to stay between 34-40°F. We used a DS18B20 digital temperature sensor, which communicates over OneWire. The firmware logs temperature every 60 seconds and sends an alert if it drifts outside the range for more than 10 minutes. The cooling unit has its own microcontroller (an ATtiny85) that runs a simple PID loop — the main nRF52840 just tells it the target temperature.

We shipped the client a fully functional prototype in 11 weeks. That included:

- Week 1-2: Requirements gathering and component selection

- Week 3-4: PCB layout and ordering from JLCPCB

- Week 5-7: Firmware development on development boards while waiting for PCBs

- Week 8: First board bring-up and debugging

- Week 9-10: Integration testing with the actual vending machine mechanics

- Week 11: Field testing in their office

The first field test was brutal. The machine worked perfectly in our lab at 72°F, but in the office break room, the cooling unit's compressor startup caused voltage drops that reset the ESP32. We added a 470μF capacitor on the ESP32's power rail and a software debounce on the power monitor pin. Fixed.

Three things stood out from this project:

Power management matters more than you think. The vending machine has three separate power domains: the 24V motor system, the 12V cooling system, and the 3.3V logic. We initially tied all grounds together with a single trace. That caused ground loops that corrupted sensor readings. We ended up using a star ground topology with separate return paths for each domain.

OTA updates need fallback. We pushed a firmware update that broke the MQTT reconnection logic. Suddenly, thirty machines in the field couldn't report inventory. Now every update includes a watchdog timer — if the machine can't reconnect to the cloud within 5 minutes of booting the new firmware, it rolls back to the previous version.

Users interact differently with office machines. People in offices tend to buy the same items at the same time every day. Our machine's data showed peak usage at 10:30 AM and 3:00 PM — coffee break times. The client used this to schedule restocks during lunch, when usage dropped to near zero.

The client deployed 50 units across their office campuses in Bangalore and London. Each machine now runs for an average of 14 days between restocks (compared to 7 days with their old machines). Inventory accuracy improved from roughly 80% to 97% — they actually know what's in each machine without sending someone to check.

The full system — custom PCB, firmware, cloud backend, and 3D-printed enclosure for the electronics — cost about $180 per unit in BOM, excluding the mechanical vending mechanism. The client estimates they're saving $40 per machine per month in reduced restock trips and fewer out-of-stock complaints.

We're now working on a second revision that adds Matter protocol support, so the machines can integrate directly with office building management systems without requiring a separate cloud account. That's the next step.