Managing compartments, access permissions and delivery events together

Custom device development for smart lockers and delivery systems

We develop electronics, embedded software, mechanical design and server applications for manufacturers of parcel lockers, storage lockers and business-specific equipment issue systems. VOMRO integrates the device's physical behaviour with the operating workflow, from locks and door sensors to code or QR authorisation and delivery records, within the same project.

Describe your project Explore the technical scope
Custom PCB control board, lock module and door sensor connections in a smart locker's internal service compartment
Representative application image.
ApplicationDelivery, storage and equipment
ControlLocks, doors, permissions and event records
DeliverySource files and technical documentation

Your project, your product

Developed confidentially and delivered with source files.

We may work with a confidentiality agreement (NDA) before sharing technical details. At the end of the project, we deliver the source codes, design files and technical documents we have developed to you.

  • NDA before sharing technical information
  • Clear deliverables agreed at the outset
  • Source and technical files at the end of the project
Our confidentiality and delivery process

VOMRO engineering approach

Opening a compartment and completing a delivery are different events.

A smart locker project must establish not only that the correct door opened, but which transaction used it and what happened afterwards. Courier deposits, customer collections and maintenance access require different permissions and record types. Using the same lock command without distinguishing these events can make operating records ambiguous.

We begin by examining users and workflows before compartment counts. The manufacturer's mechanical model, lock selection, environment, existing software and servicing method are assessed together. A new branded product and adding electronics to an existing locker create different scopes. VOMRO develops the customer's smart locker device and technical infrastructure; selling or operating ready-made delivery lockers is not the default scope.

01

Different workflows for parcels, storage and equipment issue

Parcel lockers emphasise deposit and collection, storage lockers session initiation and retrieval, and equipment lockers issue and return. Define which event makes a compartment empty or unavailable. Document operating rules for assigning differently sized compartments, cancelled transactions and uncollected contents.

Separate locker, compartment, device and transaction identities. A compartment's physical condition and its server reservation are not stored as the same state. Define how the previous transaction closes before reassignment. This model helps manufacturers use shared electronics across locker sizes and integrate more clearly with their customer's existing software.

02

Lock modules, door sensors and mechanical fit

Lock drivers are designed for the module's power supply and operating method. Door-open detection, lock status and separate content detection where required are assessed. Sending a lock command does not prove the door opened; a closed door does not prove that every lock design has engaged. Specify which sensor verifies each physical state.

Door alignment, hinges, strike plates and cable routes are considered with the electronics. Repeated opening and closing is tested with different compartment sizes and fill conditions. Connector arrangements and module replacement are planned to reduce servicing mistakes. Physical durability of locks and the cabinet is included in testing according to the environment and acceptance targets.

Numbered locker doors with keyed mechanical locks
Numbered lockers and mechanical locks.
03

Defined access permissions using one-time codes and QR codes

A code or QR code carries permission for a particular transaction and compartment, or provides access to that permission record. Define when permission starts and expires, its usage count and cancellation behaviour. Knowing a visible compartment number must not confer permission to open it. The interface response to reading errors and invalid attempts is also designed.

Transaction identities manage scenarios in which a repeated command must not reopen the same delivery. The event that consumes permission matters: commanding a lock, observing the door open and completing delivery are different decisions. Offline operation requires separate rules for local checks of expiry, cancellation and reuse. Acceptance includes behaviour when the device's clock is invalid.

04

Verifying deposit, door closure and delivery events

A door opening and closing does not by itself prove that contents were deposited or collected. User confirmation, workflow steps and suitable sensing can be assessed together. The system records the evidence used to change delivery status. Courier activity, end-user access and service openings are not reported as the same delivery event.

Define when an alert is raised for a door left open and how the compartment returns to service. Create states for selecting the wrong compartment, a door failing to open and an abandoned transaction. The local screen and central software share the same event model. Operators can inspect command time, physical door state and user actions separately; an unknown condition is not presented as a definitive delivery outcome.

05

Offline event recording and synchronisation after reconnection

Which access remains available offline follows the operating requirements. Do not assume every permission is stored locally or a new remote reservation immediately reaches the device. Plan local capacity for compartment states, door events and consumed permissions. Record event time separately from server arrival time, retaining sequence and device identity.

Uploading the same event again after reconnection must not create a second delivery. Define which information has authority for each action when local records conflict with server reservations. A late opening command must not execute for an expired transaction. The dashboard shows last communication time and data freshness. Offline operation therefore produces events that can later be compared and explained, rather than merely accumulating data.

06

Power loss, restarting and controlled servicing

The physical behaviour of locks during power loss is assessed with the selected modules and mechanics. After power returns, device records and actual door states are checked. Tests verify that startup does not issue arbitrary opening commands or repeat an unfinished transaction as new access. If backup power is required, its tasks and duration are specified separately.

Servicing procedures identify which authorised person may access which compartment and for what reason. Mechanical access, module replacement and recommissioning are linked to records. Sensor replacement includes checking the correct compartment mapping. Maintenance screens are separate from normal user interfaces. Operating procedures for door faults matter as much as device development; servicing permission is not delegated to a shared account with unlimited access to the entire locker.

07

Management dashboard, account permissions and proportionate data use

Separate the information and actions available to operators, couriers, service staff and administrators. Not every account can open all compartments or edit records. Track who created a remote command and for which transaction. Account or device deactivation, credential renewal and permission checks after servicing are included in the initial scope.

Limit personal data to what the operating scenario needs. Where the device can operate using only a transaction ID, avoid unnecessary names or contact details. Define required event data instead of logging QR codes and access codes openly. Retention periods, access and deletion responsibilities are agreed with the customer. Integration with existing delivery or business software also requires clarity on data ownership and responsibilities between systems.

08

Modular PCBs, wiring arrangements and pilot device testing

The division between central control and compartment modules depends on locker scale. Lock outputs, sensor inputs, display, communication and power architecture are designed together. Simultaneous loads and long cable runs are assessed. Board access, electronics housing and wiring harnesses are checked in mechanical CAD. Common and varying parts across models become traceable configurations.

Pilot tests cover open/closed doors, lock commands, reused codes, connectivity loss and power interruptions. A success message on screen alone is insufficient for acceptance. Define production programming, compartment mapping and functional tests. Prototype PCB fabrication and assembly support are offered only for customer projects developed by VOMRO. Findings are recorded against the relevant hardware, mechanical and software revisions.

09

The manufacturer's project, confidentiality and technical file delivery

At your request, we sign an NDA before technical details are shared. Locker concepts, workflows and integration information are handled within the customer's project. Initial discussions can cover use, compartment structure, locks, installation environment and existing software. Unresolved points are clarified through requirements and prototype work.

Project source code, schematics, PCB sources, mechanical CAD and technical documents are delivered at completion. The list of build, installation, compartment mapping, interface and testing information is agreed upfront. Third-party reader, tool and library licences are explained separately. The customer receives a documented technical package matching the working device and usable for subsequent production or maintenance.

Match smart locker use to the business's delivery and access rules
UseMain transactionControl focusExample acceptance criterion
Parcel delivery lockerDeposit and authorised collectionTransaction-to-compartment mapping and delivery eventsManaging repeated codes and uncertain door states
Storage lockerStarting a session and retrieving contentsValid access and compartment reuseUnfinished sessions and restarting
Equipment lockerAuthorised issue and returnUser roles and operating record rulesDistinguishing service openings from normal deliveries

How it works

A clear process from start to delivery.

Not every project looks the same; however, the measurable requirement, controlled revision, and field verification steps remain unchanged.

  1. 01

    We define the workflow

    Together, we define users, compartments, access rules and the delivery event.

  2. 02

    We develop the device

    We design locks, sensors, boards, mechanics, displays and server software within a shared architecture.

  3. 03

    We try scenarios

    We validate code reuse, door faults, offline operation and power loss in the pilot.

  4. 04

    We hand over the source files

    We deliver approved source code, designs and manufacturing/service documentation.

Frequently asked questions

Before starting the project

The technical scope, deliverables and test plan are clarified together according to the requirements of your project.

Can you add smart control to our existing metal lockers?

A scope can be developed after assessing locks, doors, sensor placement and wiring. Mechanical fit, access flow and acceptance testing with actual compartments are evaluated together.

Can a one-time code work without internet access?

A suitable offline flow can be designed if the necessary permission data is available locally. Limits concerning expiry, cancellation, clock information and reuse checks are defined upfront; immediate delivery of every remote change is not assumed.

Does closing the door mean delivery is complete?

That depends on the application. Door movement alone does not prove that contents were deposited or collected. Together, we define the event that completes delivery using the user step and required sensing method.

Do all doors behave the same way during power loss?

No. Lock type, mechanics and power architecture affect the result. Interruptions, restarting and authorised service access are tested with the actual modules, with expected behaviour documented in the acceptance list.

How are the NDA and source file delivery handled?

At your request, we sign an NDA before technical details are shared. Project source code, electronics/PCB and mechanical CAD sources, and technical documents are delivered at completion. Formats and the delivery list are defined upfront, and third-party licences are explained.

Related content

From idea to working electronic circuit board

PCB design and custom circuit board development

 From device to management panel

Server software and device management

 Open process, confidential project information

Non-disclosure agreements and project file delivery

 A complete working device for your brand

Custom product development for vending machines, kiosks and self-service devices

All product development services

Let's start with your idea

Let's talk about the product you dream of and the need you want to solve.

Submit a project request +90 534 487 98 02