Smart dispenser inventory sensing: why measuring “weight” failed but IR levels worked
A few years back, a globally recognized beverage and snack food company hired us to build a proof-of-concept prototype. The goal was to estimate stock level and report when it was time to restock. The client wanted us to design a “coffee pod dispenser” style sensor system to estimate stock levels and report when to order new inventory.
In this project, the “cups” were snack bags (chips, pretzels, and similar items) inside a box-style dispenser.
A lot of smart dispensers copy the coffee cup model: their sensors detect low stock and then trigger a refill. Unfortunately, with snack bags that is harder than it sounds, because the chip bags don’t stack evenly and shift all day long.
Context and constraints
This was a prototype, but it still had to feel like a real product in a demo. Our priorities were pretty straightforward:
Prove a sensing method that works with real variation in the product.
Keep mechanical changes small (simple mounts inside the box).
Add a monitoring path to a cloud backend.
Make the output stable enough that a non-engineer trusts it.
Snack bags don’t stack well, the clump weirdly, and even small movements can easily shift the whole pile around. This meant that picking the wrong sensor would be very easy to do. We didn’t want to measure how the pile looked on a particular day, we wanted to measure how many bags were left and then send a reorder notice.
The original idea: pressure film under the box
Originally, we wanted to try using a pressure-sensitive film at the bottom or under the box. We hoped to estimate the product count using that pressure reading, but unfortunately there were some major flaws in that plan. In all of our tests, the film was too unreliable. Since it was sensing pressure, not weight, we would sometimes get strange readings and spikes.
If all the bags clumped in one corner, the pressure reading spiked, but when you spread the bags back out, the reading would drop. that kind of inconsistency is not a calibration issue; it was a product of the core physics of that setup.
Fixing it would have pushed us into more mechanics (load spreaders, multiple sensors, more structure). It also would have been difficult if not impossible to perfectly calibrate for all the different product SKUs and use cases.
So, we moved on.
Reframe the problem: Do we need an exact count?
For auto restock, you often just need a stable answer to “are we low?” That points us to level sensing. In smart dispenser inventory sensing, a few level bands are often enough. This meant the simplest way forward was to follow a few steps:
Define a handful of fullness bands.
Detect which band you are in.
Filter the signal so it does not chatter when bags shift.
This also makes validation easier. You are not arguing about “17 vs 18.” You are checking that it drops from “mostly full” to “medium” to “low” as product is removed.
The hardware approach: thin PCB rails with IR beam breaks
We built thin custom PCBs that mount inside the box. Each PCB holds an IR LED and a receiver, forming a beam across the interior. When the pile of snack bags blocks the beam, the system treats that height as “filled.”
We used 4 or 5 detection levels:
Beam near the bottom = “almost empty”
Beams higher up = higher fill levels
Count blocked beams, then map that to a level estimate
The key detail was optics, because maintaining tight alignment inside a box is risky. We chose IR LEDs with a wide, flat pattern to give us more tolerance for mounting variation and box flex. That choice also came with the added benefit of making the prototype repeatable.
This kind of sensor selection and integration sits in the overlap of hardware and firmware. It is the day-to-day work behind electronics design services and embedded firmware development services.
Mechanical integration details that mattered
Even for a proof of concept, the question “where does this mount on the product?” can make or break the demo. The PCB approach helped with this issue because it was thin enough to fit without stealing usable volume but still rigid enough to hold alignment without extra brackets. it was also easy to iterate (rev the PCB, swap it in, re-test). For our demo, we wanted a sensor stack that could be assembled multiple times and achieve the same result each time.
Why beam breaks were a better fit than pressure
Beam breaks are not perfect, but they avoided the failure mode that killed our original pressure-film idea. IR beams are not affected by weight distribution, nor are they sensitive to weight changes between bags of different products. The sensor beams were also a good resolution for reordering, since we don’t need an exact count, just a general fullness level. And finally, there were almost no moving parts, which made the prototype extremely easy to build.
IR beams also fail in a more predictable way than a pressure sensitive film does. A noisy beam is usually local, which means you can filter it. A pressure reading that swings with pile shape is not random noise, so software filtering does not save you.
What we did not do (on purpose)
We could have used cameras, time-of-flight, or other sensing. Those would work, but they also add lighting issues, occlusion, privacy questions, and computation load.
For this project, we wanted a simple stack that needed little to no unit specific calibration, is fast and easy to build, and maintained the expected behavior even in messy real-world situations.
Given that constraint set, multi-level beam breaks were a better trade than cameras or other sensors.
Firmware: make a messy physical world look stable
Snack bags move when a user pulls one out. This means that if you just report raw sensor state, the UI looks incredibly broken. To answer this, we treated each beam as a signal that needed conditioning:
Sample at a fixed rate.
Debounce and time-filter each level.
Add hysteresis so the reported level changes only when it stays put.
Trigger “low stock” only after the level stays below a set threshold for a set time.
These checks are nothing exotic, but they turn a set of “mostly right” sensor data into stable behavior for the user. This is a common pattern in connected products and kiosks, and it is part of our IoT product development work.
Reporting: Raspberry Pi bridge to the cloud
For the proof of concept, we used a Raspberry Pi as a reporting node. It connected to a cloud backend and sent a message when the level dropped below a configurable threshold.
Using a Pi kept our iteration fast and easy (networking, logging, quick config changes). We also added basic robustness, so the demo did not depend on perfect Wi-Fi. In addition, we made sure to locally buffer sensor events, as well as integrate a retry with backoff protocol. We also made sure there was a clear distinction in the UI between “low stock” and “cannot report,” so as to avoid any confusion.
If the sensing works and the data model is clear, the path from a Pi-based proof of concept to product hardware is usually straightforward. That transition is what we mean by rapid prototyping to production support, and it worked well for us on this project.
Results
We delivered a working proof-of-concept prototype that:
estimated snack level using multiple IR beam heights
reported a stable level (no constant chatter in normal use)
triggered cloud messages when stock stayed below the set threshold
As a smart dispenser inventory sensing proof of concept, it showed the user-visible behavior the client needed: a dependable reorder trigger.
Lessons learned
Start with the decision, not the measurement. “Are we low?” is often the real question.
Pressure sensors need a controlled load path. Free-moving products break that assumption.
Discrete level sensing is a practical sweet spot. Four or five bands can be enough.
Design optics for assembly tolerance. Wide patterns beat tight alignment.
Firmware is where prototypes become believable. Filtering and hysteresis matter.
CTA
If you are building a connected dispenser, stock monitor, or smart container and the sensing is not behaving, we can help you simplify the problem and get to a prototype that works. See embedded systems consulting or schedule a call.
