Renovotec · Node.js & device integration
Light the right shelf. Wait for the pick. Keep the demo moving.
A pick-by-light demonstration turns a software instruction into a physical action: show the quantity, illuminate the appropriate label, receive confirmation and continue. The application must distinguish asking a device to act from observing that the action has happened.
I developed the Node.js integration with SOLUM AIMS and electronic shelf labels. The work progressed from command/confirmation timing to a looping customer demonstration with multiple active picks and product-data updates. Customer demonstration is the supported outcome; production deployment is not claimed.
I developed a Node.js demonstration integrating SOLUM electronic shelf labels with a picking sequence. The application requests a light, waits for pick confirmation and advances through the products.
The work began with checking command and confirmation timing, then developed into a looping customer demo with multiple active picks and product-data updates.
An accepted request does not mean a physical label has lit up. And a lit label does not mean someone has pressed its button. I worked through those states instead of treating the API response as the end of the task.
The demo logs track processing, success and pick confirmation. That made it possible to see where the sequence was waiting, rather than guessing from a motionless console.
Early timing output showed impossible one- and two-hour delays. I questioned the results and investigated timestamp interpretation rather than presenting them as device latency.
Later iterations used multiple active picks. Variable flash delays and intermittent socket disconnections exposed further reliability work. Individual timing samples are not a guaranteed response time, and proposed recovery changes are not the same as a completed endurance test.
The photograph shows the working hardware setup; the development record includes actual pick-confirmation logs. Renovotec has demonstrated the system to customers.
This is a practical example of my JavaScript work beyond websites: integrating an external API with physical devices, observing their state and turning that into a usable demonstration.
The following decisions connect the implementation to its practical constraints. Each separates what I changed from what still needs verification.
Different evidence answers different questions. This record distinguishes a visible demonstration, implementation history and validated operational outcomes.
What it supports: Shows active label lighting and pick-quantity displays in the demonstration setup.
What it does not establish: Customer branding and QR codes are redacted. The image does not establish production use.
What it supports: Record command progress and physical pick confirmations, supporting the event-sequencing account.
What it does not establish: Individual observations are not guaranteed latency figures; raw internal logs are not published.
What it supports: The system has been demonstrated to customers, as confirmed in the project account.
What it does not establish: No claim is made about signed customers, adoption, throughput or error reduction.
This was JavaScript integration work with a physical feedback loop. Useful diagnostics had to explain where a task was waiting, not simply whether an HTTP call had returned successfully.
A further acceptance programme should cover disconnections, delayed confirmations and sustained multi-pick operation. Proposed recovery behaviour must be tested before it is described as an operational guarantee.