From a real problem in a packing station to a visual traceability platform

1. The search for a solution that already existed
2. The Hikvision path that we could not use
3. The conversations that helped build the logic
4.  The central technical discovery 
5.  The first laboratory 
6.  The first demonstration to the client 
7.  The first real implementation 
8.  From a station to the entire operation 
9.  The infrastructure problems 
10.  The migration from Hikvision to Uniview 
11.  The birth of Sentria Agent 
12.  The blackout that tested the system 
13.  The error between stations 12 and 13 
14.  The stabilization 
15.  How Sentria works today 
16.  What problems it helps to solve 
17.  What differentiates Sentria 
18.  For which companies it is designed 
19.  What a company needs to implement it 
20.  The future of Sentria
21. Conclusion
    

Among the little information available about this type of solutions, we found a proposal from Hikvision aimed at package tracking.

The logic was similar to what we needed: a scanner registered the code, a camera recorded the operation, a server related the scan to the exact moment, and later the code could be searched and the corresponding recording retrieved.

It seemed to us that it was no longer necessary to invent anything. If the tool existed and we had the manufacturer's support, we could install it, test it, and offer it to the client.

We contacted Hikvision and requested access to a temporary license or a demonstration. Our intention was to set up a test station within our office, understand the system before offering it, and send the client a real demonstration that it worked.

After several emails, we did not gain access to a demonstration under our testing conditions.

We did not immediately decide to develop a commercial product. We established a much simpler condition:

«If we had time and available resources, we would try to build a small demonstration. If it worked, we would present it to the client. If it did not work, we would abandon the idea without continuing to consume resources.»

Before writing the system, I spoke with close people who knew different areas of technology.

One of the most important conversations was with José Serpa, who had experience with camera systems. I explained the problem, the solution we had found in Hikvision, and the limitations. I also asked him if he knew another brand or tool that could solve something similar.

We didn't find any close alternative.

So we stopped talking about brands and started discussing how cameras, NVRs, and triggers actually worked. José proposed the possibility of connecting a button or a signal that would activate at the moment of scanning. That pulse could indicate to the camera or the system that an event was occurring at that moment that needed to be recorded.

The idea seemed brilliant to me because it helped to understand the missing element: the system needed a mark that indicated the exact moment.

I also spoke with my friend Jesús Martínez, who at that time was working in California, within the technological environment of Silicon Valley. I presented the idea to him and asked if he knew of an application, a company, or any developer who had worked with something similar. Jesús was involved with delivery projects using drones and artificial intelligence, but he didn't know of a solution close to what we were looking for.

These conversations did not produce a finished product, but they helped to build the logic. I started to connect three pieces: the real need of the client, the structure we had observed in the Hikvision solution, and the idea of using the scan as the event that marked the exact moment within the video.

The first idea was to physically activate a camera at the moment of scanning.

However, while we were studying how NVRs worked, we understood that we did not need to turn on or start recording a camera every time someone scanned a package.

The camera could record continuously. What we needed was to accurately log the scanned code, the station where it occurred, the date, the exact time, and the camera corresponding to that station. With that information, we could request from the NVR the video segment that corresponded to that moment.

The scanning did not have to activate the recording. The scanning could become a timestamp within an already existing recording.

That was one of the discoveries that defined Sentria.

«The camera documented what happened. The scanner identified the product. Sentria had to build the bridge between the two.»

During a period when we had a lighter workload, I personally focused on studying how we could build the demonstration.

We researched how to communicate with the cameras and the NVR, how to query the recordings, and how to extract only the necessary segment.

We created a basic architecture: a client program installed at the station, a central server, a database, a record for each scanned code, a relationship between station, camera, date and time, a search engine, and a process to generate the corresponding video.

The first version was developed mainly with Python, Flask, HTML, SQLite, and FFmpeg, with communication with the NVR and video processing via RTSP and HLS.

At that moment, there was no great interface. Much of the testing was done by directly observing the console and the results of the code. We saw what data arrived, when it arrived, what the latency was, what time format the NVR used, which channel corresponded to each camera, if the fragment started too early or too late, and if the retrieved video actually matched the scan.

We also discovered that each manufacturer could handle communication, schedules, and recording queries differently. Our prior knowledge of cameras and video surveillance was essential to understand those differences.

Before installing anything in the client's operation, we built a small packing station inside our office. We installed a camera, a scanner, a work table, a client computer, an NVR, a test server, and products and labels to simulate packages.

We were not just testing code. We were physically reconstructing the client's process to understand how the system would behave within a real station.

The lab video documents that by October 2, 2025, we already had a functional flow: a code was scanned, the system recorded the code, the station, and the time, the server queried the NVR, the video fragment was generated, and the user could play back the associated evidence.

Only after verifying that the logic worked did we begin to build a more user-friendly interface.

When we had a result that we considered stable enough, we spoke with the client again.

We did not present an abstract idea. We showed you the system working. We sent you a video where you could see how a code was scanned, how it appeared in the searcher, and how the exact moment of packaging was retrieved.

The response was direct:

«That's what I want. I like it. Let's do it.»

The client requested to install a first demonstration within a real station and check how it performed in production. At that moment, the clock started ticking. It was no longer just an internal investigation: we had made a delivery promise.

We proposed a price for the demonstration with a favorable condition for the client: if the pilot worked and the complete project was approved, the amount paid for the test would be deducted from the final project.

This was also important for Team Gears. The demonstration began to generate the necessary resources to keep the development active. Instead of indefinitely financing the project with general company resources, Sentria began to sustain part of its own evolution.

The first pilot was installed in one of the stations with the highest workflow.

For the server, we used a mini PC because the code was lightweight and did not initially require excessively large infrastructure. That experience gave rise to the concept we later called Sentria Box: a compact device with enough capacity to process the records and coordinate communication without introducing significant delays.

The first installation used a small server, a Hikvision NVR of approximately 4 TB, a Hikvision camera, a scanner, a workstation computer, the Sentria client, the Sentria server, and remote access for monitoring.

The system started to work and produce results. However, it also began to show us everything that the lab could not teach us.

In the actual operation, there were different user sessions, programs that could close, processes that did not remain active in the background, equipment used simultaneously for other tasks, network changes, reboots, interruptions, and Windows behaviors that did not appear in our office.

We had several initial crashes. At times, the console would close. Other times, some program or process would stop the client. Some stations would stop communicating with the server. Each problem forced us to review, correct, and retest.

The first demonstration lasted approximately six months, or even a little more, within the active operation. During that period, we constantly monitored that the scans arrived, that the database had the records, that the video corresponded to the code, that the server remained active, that the station continued to communicate, and that there were no delays or losses.

We also performed random checks: we looked for processed codes and verified that the system returned the correct video. After the initial corrections, the pilot began to work stably. There came a time when we could leave it operating practically on its own.

After checking the results, the client made a decision: they wanted Sentria at all their stations. The request went from a single test to an installation of approximately 12 stations. There was also interest in replicating the solution in future operations in New Jersey and Texas.

That was the moment when Sentria stopped being just a specific solution for one computer. It now had to become a complete infrastructure.

It was necessary to design the structured cabling, the cameras, the position of each camera, the network ports, the NVR channels, the server, the storage, the UPS, the rack, the identification of each station, remote management, and the possibility of expanding to other locations.

The physical structure of the stations imposed significant restrictions. The distance between the upper area and the packing table was limited. A camera that was too large could interfere with the operator or miss important parts of the operation. That’s why we looked for compact and slim cameras that could be installed within the structure of each station and clearly show the package, the operator's hands, the product, the label, the sealing process, and the area where relevant movements occurred.

We carried out the cabling for the IP cameras, finished RJ45 connections, and organized each route. Each element had to be identified: station, camera, cable, port, panel, NVR channel, network address, and associated computer.

That identification was not an aesthetic detail. If a station was linked to the wrong channel, the code could retrieve a technically correct video, but belonging to another table.

The physical installation also produced problems that were not directly related to the software. One of them was the rack.

We had prepared the server, the NVR, and the UPS, but when we tried to install the server, we discovered that the rack did not have enough depth. The photographs document that the available space was approximately 16 inches, while the equipment needed about 20 inches or more, in addition to the space required for connectors and ventilation.

The server simply did not fit. We had to stop the installation, measure again, acquire a deeper rack, and reorganize the infrastructure. That caused delays.

It was a simple but important lesson:

«A solution may work perfectly in software and stop due to a few inches of difference in a cabinet.»

As we resolved cameras, servers, cabling, and racks, we also faced pressure, travel, unforeseen events, and responsibilities outside the code. There were even moments when I had to continue reviewing or updating the implementation from an airport in North Carolina.

Sentria was not developed solely from a desk. It was developed from the office, the plant, the stations, a lift, travel, and remote connections at times when the operation needed to keep moving forward.

The first version had been developed around the behavior of Hikvision. However, for the complete installation, we used Uniview cameras and an NVR.

In theory, both brands solved similar functions. In practice, their protocols, formats, and communication methods were different. When we started the implementation, we discovered that the code could not communicate with Uniview exactly the same way it did with Hikvision.

We had to study how Uniview delivered the recordings, how it handled dates and times, how it identified the channels, how it responded to requests, how to extract the correct snippet, and how to adapt the processing without introducing delays.

The migration took time, but we finally managed to get Sentria to work with Uniview without a noticeable loss of accuracy or latency that affected the operation.

This also changed the way we viewed the product. Sentria should not be tied forever to a single brand. It needed to have a structure flexible enough to adapt to different video platforms, as long as they met the necessary technical requirements.

After installing several stations, another problem arose. Some computers went offline. Sometimes the Sentria client would close, or some external process seemed to stop it. The operator could continue using the computer without realizing that Sentria had stopped communicating with the server.

Initially, we had to remotely access the stations and check each one manually. That was not sustainable.

In response, we created Sentria Agent. The agent was installed on the stations to report if the server was available, if the Sentria process was active, if the station was communicating, if there were pending logs, what version was installed, and when the last communication occurred.

Subsequently, we added tools to restart components, reinstall tasks, update the client, install modules, run test scans, update the agent, and apply actions on a station or on all.

Sentria began to transition from a tool that recorded events to a platform that could also monitor its own operation.

"We no longer relied solely on a person discovering a failure. The system could inform us that a station had stopped responding."

While we were investigating why some stations were disconnecting, a general blackout occurred in the plant. Sentria generated multiple alerts because almost all the stations stopped responding.

We contacted the person in charge of the operation and asked if something had happened with the network or electricity. The answer was clear: a general blackout had occurred.

After the power was restored, a second problem appeared. Several computers and the server changed their IP address. This interrupted communication between some components. We tried to restore the system remotely over the weekend, but many stations were not accessible because there were no users working on them.

When we regained access, we corrected the communication and the stations began to send the records that had been pending. The estimated loss was minimal or none.

That event demonstrated the value of maintaining a local queue of records. Even if a station temporarily lost connection, not everything had to disappear. The data could remain pending and synchronize when communication returned.

«An interruption no longer automatically meant a definitive loss of evidence.»

During that same stage, it was reported that some codes associated with station 12 were showing video from station 13. In other cases, the user saw an empty station when expecting to observe activity.

Initially, it might have seemed like an error in the search or in the extraction of the video. After reviewing the configuration, we discovered the cause: stations 12 and 13 had been swapped during installation. It was a human sequencing error. Sentria was querying the channel it had configured, but that channel had been linked to the wrong station.

We corrected the configuration and conducted tests with specific codes. Each record began to show the corresponding video again. We also offered to review and recover, as much as possible, the historical data related to the affected period.

This incident reinforced an important implementation rule:

«The physical station, the computer, the cable, the port, the camera, the NVR channel, and the logical configuration must represent exactly the same sequence.»

It is not enough to install the software correctly. Traceability depends on the entire chain being correctly identified.

After the blackout, the correction of addresses, the synchronization of records, and the repair of stations 12 and 13, we continued monitoring the operation.

At the close of this collection, Team Gears had not received new reports or alarms related to system failures after those corrections. The stations were operating stably. Each record was related to the corresponding video with no reported setbacks.

The capture from the panel on July 29, 2026, documents 302,877 recorded scans, 12 active stations, 1 location, 9 active users, all stations reporting operational status, active processes, correct communication with the server, and zero pending records in the displayed queues.

These numbers do not represent a demonstration. They represent a tool working within a real operation.

Sentria connects the physical action of scanning a code with the visual evidence of an operation.

An operator prepares a package at a station. During the process, they scan the corresponding code. The Sentria client records the code, the station, the date, the exact time, and the information needed to identify the camera. The server receives and retains the record.

When an authorized user searches for the code, Sentria queries the corresponding recording and generates a clip that includes the moment of the operation. The user can then search by code, filter by date, filter by station, play the video, download the evidence, share it via secure access, query records from a web interface, work with users and permissions, check the status of the stations, and diagnose interruptions.

The architecture keeps the main server within the client's operation, allowing for local work and maintaining control over the video and records. At the same time, secure web access allows for information retrieval without directly exposing the entire internal network.

Sentria does not replace the recording of the cameras. It also does not replace the client's operating system. Sentria acts as the layer that connects the event, the code, the station, the time, the camera, the video, and the evidence.

Sentria was initially created to investigate claims in fulfillment operations, but the problem it solves appears in many industries.

Some cases: a customer claims that a product was missing from the package; the item received does not match the order; a label was placed on the wrong box; an operator scanned a different code; the package left correctly, but the claim occurred afterward; the company needs to demonstrate how a shipment was prepared; management wants to investigate a human error; it is necessary to verify at which station an operation was processed; evidence needs to be located without reviewing hours of footage; a station stopped reporting and it is necessary to determine what records are pending.

The system does not only benefit the company. It can also protect the customer and the employee. The evidence can demonstrate that a claim is valid and that an error occurred during packing. But it can also show that the employee correctly performed the process and that the product was indeed placed inside the package.

Sentria is not designed solely to deny claims. It is designed to help reconstruct what really happened.

Sentria did not start as a generic software that we later tried to find a client for. It started within a real operation.

Each function was born from an observed problem. The search function was born because reviewing recordings manually was too slow. The station relationship was born because each table had a different camera. Video extraction was born because the client did not need to download entire hours. Sentria Agent was born because some stations stopped responding. Alerts were born because it was necessary to detect drops before losing information. Pending queues were born because a disconnection should not delete records. Secure access was born because the system could not be limited to a local IP address. Compatibility with Uniview was born because the real infrastructure did not use the same brand as the lab. Meticulous identification was born after understanding the impact of investing in two stations.

«Sentria evolved through the real problems it encountered while working.»

That is one of its main differences. It was not built just to function under ideal conditions. It was built while facing power outages, IP changes, process shutdowns, Windows sessions, human errors, differences between manufacturers, physical limitations, incorrect racks, active stations, and operations that could not be stopped indefinitely.

Sentria can add value in operations where there is a physical action that can be identified by a code and that requires visual evidence: fulfillment, logistics, warehouses, distribution centers, repackaging, order preparation, returns, merchandise classification, quality control, light manufacturing, receiving and dispatching, and processing of assets identified by code.

Not all companies need Sentria. It is specially designed for operations where there are many transactions, where claims have a significant cost, where manual video search takes too much time, where it is necessary to verify what happened with a specific item, and where traditional traceability does not show how the operation was physically executed.

Implementation depends on the operation, but it usually requires a defined workstation or point of work, a code that identifies the operation, a scanner, a computer per station or compatible equipment, properly located cameras, stable wired network, compatible NVR, sufficient storage, local server or approved infrastructure, exact identification of stations and channels, users and permissions, support access, and retention and security policies.

The camera must clearly show the relevant area. It is not enough to place a general camera on the ceiling. The angle, distance, lighting, and position must allow distinguishing what really happens during the process.

The amount of storage will depend on the number of cameras, resolution, frames per second, compression, whether the recording is continuous or motion-triggered, and the required retention time.

Sentria began by addressing a specific need in one location. But since the start of the expansion, the client raised the possibility of using it in other operations.

The product vision includes multiple locations, centralized management, more stations, different camera and NVR manufacturers, more advanced alerts, reports, auditing, tools for sharing evidence in a controlled manner, integrations with other platforms, APIs, health monitoring, user and role management, better remote diagnostics, recovery automation, and greater ease of implementation through Sentria Box.

The goal is not to turn Sentria into a feature-rich platform that no one uses. The goal is to maintain the same logic that gave rise to the project:

"Observe a real problem, understand it, build a useful solution, and test it within the operation."

Sentria started with a side-mounted Wi-Fi camera installed at a packing station. The camera recorded, but finding the evidence was too complicated.

Buscamos soluciones en el mercado y encontramos opciones técnicamente capaces, pero económicamente difíciles de justificar. Intentamos trabajar con una solución existente de Hikvision, pero no pudimos conseguir la demostración ni el soporte necesario. Entonces decidimos probar si podíamos construir nuestra propia alternativa.

We talked to trusted people, studied how the cameras and NVRs worked, built a lab, wrote the first version, tested it, made mistakes, and brought it to production.

The first demonstration became a station. The station became twelve. The test became a platform with a server, agents, alerts, users, secure access, and over 300,000 records.

During the process, we had outages, protocol changes, network issues, a rack that was too small, inverted stations, a power outage, pending records, and updates made while traveling. We did not hide those problems because they are part of what built the solution.

Sentria did not reach its current state because everything worked correctly from day one. It arrived because every problem was observed, diagnosed, and turned into an improvement.

«Sentria was born when we understood that recording an operation was not enough. That recording had to be turned into evidence that could be found, understood, and used when it was really needed.»

Ver Demo de Sentria

Does your operation pack and scan? The demo is open.