DEV Community: Ethan Tan

A minimal acceptance event for a bottle return machine

Ethan Tan — Mon, 26 Oct 2026 17:25:26 +0000

A return machine is only useful to the scheme operator if each insert becomes a record.

The smallest record I would store:

container id (barcode or scheme code)
decision: accepted or refused
reason code when refused
machine id and timestamp
refund id, only if a payout was committed

Without the reason code, "it rejected my bottle" cannot be reconciled. Without the refund id, a retailer dispute is just two stories.

I work on RECYNEX. Primer: https://www.recynex.com/news/what-is-a-reverse-vending-machine/

Three events, not one, when a return machine accepts a bottle

Ethan Tan — Mon, 26 Oct 2026 14:56:00 +0000

A bottle-return point that writes a single "recycled" row will lie the first time the link drops.

Split one visit into three facts the device can prove on its own:

accept — the machine matched a container (barcode or shape) and committed to taking it. Persist this on the device before the compactor or shutter moves. Key it on machine id plus a local sequence, not a server clock.
store — the container was actually retained (compacted or dropped in the bin). An accept with no store is a jam, or a person who pulled the bottle back out.
payout — the deposit or reward was issued (cash, voucher, or scheme credit). This fails on its own when the scheme API is down. Queue it. Do not roll back the accept, or you end up with a bottle in the bin and no record.

Replays after reconnect should return the original ids. If accept and payout share one transaction, a timeout makes you either double-pay or delete a container you already kept.

A short public note on what the machine checks per insert: how a reverse vending machine handles one container.

Queueing reverse-vending return events when the store link drops

Ethan Tan — Mon, 26 Oct 2026 13:55:41 +0000

A return machine in a supermarket is a small edge device with a bad network. Shoppers do not wait for your cloud. If the uplink blips, the machine still has to accept a bottle, print a receipt, and remember that event until the link is back.

This note is the shape of that queue, not a product pitch.

What has to survive offline

Each accepted container is one event, not a row you update in place. A useful payload is small and idempotent:

{
  "event_id": "01J9…",
  "device_id": "store-14-rvm-2",
  "accepted_at": "2026-10-26T12:04:11Z",
  "material": "pet",
  "barcode": "9300675000000",
  "session_id": "s-8841",
  "scheme": "deposit"
}

event_id is generated on the device (ULID or UUIDv7). The cloud treats a repeat of the same id as a no-op. That matters because the store Wi-Fi will deliver the same batch twice.

Local queue

Keep an append-only log on disk, not in memory:

Validate the container (barcode or vision result) before you enqueue. A rejected item is not an event.
Append the event and fsync. The receipt printer should run only after that write succeeds. Otherwise a power cut prints a voucher the cloud will never see.
A worker drains the log when the uplink is healthy. Send batches of a few dozen, in accepted_at order, with the last acked event_id as a cursor.
The server acks ids, not "the whole request". Drop only the acked prefix. Leave the rest for the next attempt.

Clock skew is normal. Do not sort the fleet by device clock alone. Store both accepted_at (device) and received_at (server), and let settlement use the scheme's rules.

What not to do

Do not hold the shopper UI on an HTTP call to the cloud. Recognition and the receipt are local. Sync is background.
Do not key the event on barcode + timestamp in seconds. Two cans in the same second collide, and a retry looks like a new return.
Do not compact or delete the on-device log until the ack is durable. A full disk should refuse new returns with a clear message, not drop history.

Vision sits beside this, not inside it

If the machine uses a camera to tell PET from a look-alike, that score belongs on the event as evidence (vision_label, confidence), but the accept/reject decision should already be made before enqueue. Re-running the model in the cloud is for audits, not for changing a receipt the shopper already holds.

Operators who run a fleet of these machines end up with the same three questions: is the device online, how far behind is its cursor, and which sessions never got an ack. That is a queue-depth problem more than a recycling problem.

I work on this class of system at RECYNEX. A higher-level description of the return flow (not the queue) is on our site: https://www.recynex.com/news/what-is-a-reverse-vending-machine/

Reading a STEP file's volume and weight in the browser: what actually happens

Ethan Tan — Tue, 13 Oct 2026 12:50:32 +0000

Correction (21 October 2026): The earlier text conflated a possible browser/WebAssembly implementation with CADProps, overstated what STEP files contain, and used an incorrect inch-to-millimetre volume factor. CADProps uploads files for server processing; it is not a local-only browser/WASM tool. This factual correction was prepared with AI assistance.

STEP (ISO 10303) files can carry different geometric representations. AP242 supports tessellated part geometry as well as B-Rep geometry. So "how much does this part weigh?" is a geometry question before it's a math question.

1. Parse and identify the representation. Open CASCADE compiled to WebAssembly is one possible browser implementation, not a description of CADProps. A display mesh and the underlying B-Rep are different representations. Mesh-based volume estimates depend on tessellation; valid closed B-Rep solid volume can be calculated independently of display tessellation. CADProps uses server processing for uploaded files.

2. Integrate the volume. For a valid closed, consistently oriented triangle surface bounding the intended solid, volume can be calculated by summing signed tetrahedra from the origin: V = Σ (v1 · (v2 × v3)) / 6. Check watertightness, orientation and self-intersections; an arbitrary positive sum is not proof of a valid solid.

3. Multiply by density. Steel ≈ 7.85 g/cm³, aluminium ≈ 2.70, PLA ≈ 1.24 are approximate density assumptions, not material specifications. Confirm the file's units instead of assuming millimetres. For volume in mm³, conversion to cm³ is /1000. A solid-material estimate is not the filament mass of an infilled print.

4. Gotchas. Summing component occurrences can double-count overlapping material; it is not the same as measuring their geometric union. Open surface shells do not establish an enclosed solid volume. One inch is exactly 25.4 mm: reading inch coordinates as millimetres makes lengths 25.4 times too small and volumes 25.4³ = 16,387.064 times too small.

FreeCAD's Shape.Volume is a geometry property, not a substitute for checking the shape's validity, units and component scope. Disclosure: I work on CADProps. The earlier phrase "built this way" was incorrect: CADProps uploads and processes files on a server. Do not upload confidential geometry without the owner's permission.