Argustechnical rooms

TicTrens operates trains in São Paulo, and along the tracks there are technical rooms that receive maintenance. The problem is operational safety: the company had no way to actively track who was inside those rooms, nor confirm that whoever went in came out.

That matters because the room is a hazardous space next to an active track. A technician who enters and is never recorded as leaving has to be detected at the time, not at the end of the shift.

How Argus solves it

Two layers that check each other.

Declaration. Before entering, the technician identifies themselves on the device. It is multi-factor, and the two steps exist for different reasons: they tap an RFID card, which identifies them without contact and without typing anything, then enter a passcode on a matrix keypad. A card is only as good as nobody losing or lending it, which is why it does not decide on its own. This records intent: who, where, when.

Verification. A camera mounted above the door counts how many people go in and how many come out, and the count goes to the database alongside the authentication events. This records fact.

Planned operations is the third reference. When all three agree, everything is fine. When they do not (more people entered than identified themselves, or fewer left than entered), there is something for someone to look at.

Why not just the camera

Computer vision counting alone tells you how many people, not which. Authentication alone tells you who identified themselves, not who walked through the door. Together, one covers the other’s gap, and that is what makes the system usable in operation.

The ESP32 and the feedback at the door

The ESP32 coordinates the embedded side: card reading, keypad, LCD display, and the feedback to the technician through an RGB LED and a buzzer. Someone standing outside a room next to an active track needs to know in one second whether they can go in, without stopping to read a screen.

The log is the product

Every attempt becomes a record: who, when, and whether it passed. Events leave the device over MQTT and land on a dashboard, and that is where the system goes from access control to an operations tool. You can see usage patterns, a denied attempt repeating, and reconcile what happened against what was planned.

MQTT was not the first choice. The initial version spoke HTTP, and we switched because the device publishes short, sporadic events to a server that may not be listening at that instant, precisely the case where opening a full request per event does not pay off.

From breadboard to enclosure

It started on a breadboard, to validate wiring and module behaviour with loose, easily swapped connections. After that the connections were soldered and everything moved into an enclosure, which is the 3D model on this page. The mechanical side is not finishing touches. It decides whether the technician can operate the device wearing gloves, whether the RFID reader sits at the right height, and whether the wiring survives someone closing the door.