Building a Smart Inventory Management System Using Raspberry Pi and IoT

We’ve been building embedded systems for close to a decade now, and one of the most common requests we get is for smarter inventory tracking. Not just barcode scanners and spreadsheets — real-time, sensor-driven systems that tell you exactly what’s on the shelf, what’s moving, and what’s about to run out.

Recently, we helped a chain of fitness centers replace their manual vending machine restocking with an IoT-based system. Their problem was simple: they had no idea which machines were empty until a member complained. Their solution? A Raspberry Pi-based inventory management system with weight sensors, RFID readers, and cloud connectivity.

Here’s how we approached it, and what we learned along the way.

The Hardware Stack

We chose the Raspberry Pi 4 as the main controller. It’s overkill for simple sensor polling, but it gives us room to run a lightweight database, handle Wi-Fi or Ethernet, and serve a local dashboard if needed. For the vending machine itself, we used:

• Load cells (4x 50kg) under each product row, connected via an HX711 ADC
• RFID readers (MFRC522) on the machine door for access logging
• ESP32 modules for wireless sensor nodes on machines far from the Pi
• MQTT over TLS for all sensor data transmission

For the fitness center deployment, each machine had its own Pi. The Pi runs a Python script that polls the HX711 every 500ms, averages readings, and publishes weight changes to an MQTT broker hosted on AWS. If a product row drops below a configurable threshold, the system sends a restock alert.

The Software Side

On the Pi, we used:

• Python 3 with RPi.GPIO and smbus2 for hardware interaction
• Mosquitto as the MQTT broker (local fallback if internet drops)
• SQLite for local logging
• Node-RED for quick dashboard prototyping (though we replaced this with a custom Flask app later)

The cloud backend runs on a small EC2 instance with:

• Node.js MQTT subscriber
• PostgreSQL for inventory history
• WebSocket push to the frontend dashboard

The result? The fitness center’s operations team can see real-time stock levels for all 12 vending machines across 3 locations. They get push notifications when a machine is 80% empty. Restocking time dropped from 2 hours per machine (checking manually) to 15 minutes (filling based on data).

Smart Vending Software Integration

This is where things get interesting. The hardware is only half the story. You need smart vending software that can:

• Handle multiple machine types (snacks, drinks, supplements)
• Support dynamic pricing (e.g., higher prices during peak gym hours)
• Integrate with loyalty programs or member IDs

We built a lightweight API layer that the Pi calls every time a product is dispensed. The API updates inventory in real-time, triggers reorder requests, and syncs with the fitness center’s existing member management system. The dashboard shows not just stock levels, but velocity — how fast each product sells per hour.

For vending machine fitness centers, the advantage is clear: no more lost sales from empty slots, no more overstocking slow movers. But there are tradeoffs we need to be honest about.

Advantages

Real-time visibility. You know exactly what’s in each machine, down to the gram. No guesswork.

Data-driven restocking. Instead of a fixed schedule, you restock based on actual consumption. This cuts waste and labor costs.

Remote diagnostics. If a sensor fails or the Pi goes offline, you get an alert. You can even reset the Pi remotely via a watchdog timer.

Scalability. Adding a new machine means plugging in another Pi and an MQTT topic. The backend handles it without reconfiguration.

Integration with existing systems. The smart vending software can pull member data from the fitness center’s CRM, enabling personalized offers or discounts.

Disadvantages

Sensor drift. Load cells drift over time, especially in environments with temperature changes (like gyms). We had to implement auto-calibration routines that run every 24 hours. Without that, the system would report false empties.

Power dependency. If the Pi loses power (and there’s no backup), you lose visibility. We added a UPS hat for critical machines, but that adds cost.

Network reliability. MQTT over Wi-Fi works fine until the router goes down. We added a cellular fallback module (SIM7000) for high-traffic locations, but that increases monthly costs.

Initial setup complexity. This isn’t a plug-and-play system. You need someone who can solder load cells, configure the Pi, and write the MQTT topics. For a single machine, it might not be worth it. For 12 machines across 3 locations, it pays for itself in 4 months.

Maintenance overhead. Firmware updates, sensor recalibration, and hardware failures — you need a process for all of it. We provide remote firmware updates via OTA, but the customer still needs someone on-site for physical repairs.

What We’d Do Differently

If we were building this again from scratch, we’d use Zephyr RTOS on an nRF52840 for the sensor nodes instead of ESP32. Better power efficiency, native BLE support, and easier OTA updates. The Pi would stay as the gateway, but the sensor nodes would run for months on a coin cell.

We’d also switch to Matter for the local communication protocol. It’s still early, but the interoperability with other smart devices (like HVAC or lighting in the fitness center) would be valuable. Imagine the vending machine automatically reducing prices when the gym is empty — that’s where this is headed.

Final Thoughts

Building a smart inventory management system with Raspberry Pi and IoT is absolutely doable with off-the-shelf components. We’ve shipped prototypes to clients in under 6 weeks — including PCB design in KiCad, firmware in C, and full 3D-printed enclosures.

But don’t underestimate the software glue. The hardware is the easy part. The real value comes from the smart vending software that turns raw sensor data into actionable restock decisions. For vending machine fitness centers, the ROI is clear: fewer empty machines, happier members, and lower operating costs.

If you’re thinking about building something similar, start small. One machine, one sensor, one MQTT topic. Get that working end-to-end before scaling. And if you need help with the firmware or PCB layout, our team has done this dozens of times — we’re happy to take a look.