DianaGate
Our own IoT unit for barrier control
The barrier at the landfill was opened by a box that could do exactly one thing: react to a missed call from an allowed number. The list of numbers was edited over SMS or a serial cable, and the system that keeps track of loads only learned about a passage the long way round. First we worked around it in software — then we built our own unit that does the same job itself and talks to the application directly.
DianaGate is a barrier control unit built on a Raspberry Pi with a 4G modem. The gate opens on a missed call from an allowed number, on the button on the enclosure, on a command from the Diana application, or on an external contact — the entrance camera, for instance, or the original GSM gate, which can serve out its days as nothing more than a contact. The unit has its own web dashboard. It shows the gate state and last opening, the list of allowed numbers synchronized from Diana, an opening log with the source of each trigger, and modem telemetry (signal strength, network registration, uptime). It also holds SIM and network settings, relay timing and service functions. Every opening is reported to Diana, where it is matched with the weighing and the plate snapshot into a single load record.
Technology
The unit runs on a Raspberry Pi 4 with a SIM7600 LTE modem on a HAT. The output to the barrier drive is switched by a relay as a volt-free contact, external inputs are galvanically isolated by optocouplers, and power comes from a built-in 230 V supply with a switch and a fuse. The firmware is TypeScript on the Oidis Framework, running under systemd as a service that starts with the device. The unit serves the dashboard from its own web server, and access to the control functions is protected by a PIN. The unit talks to the Diana application through the Oidis Hub, so an outbound connection is enough even behind NAT. The enclosure, the glands and the assembly are made in our workshop; the lid carries a QR code with the documentation and a spare SD card with the system image.
The brief
The original GSM gate was a black box. Its whitelist was maintained over SMS or through the vendor's application on a serial port, the opening log had to fit into the device's memory, and the only way out was the one the manufacturer had in mind. Load records need the exact opposite: a list of numbers driven from the application and an opening event available immediately, so it can be paired with the weighing and the vehicle snapshot. On top of that came an operational requirement — the barrier must open even when the internet is down, or when someone without an allowed number is standing at the gate.
The solution
We took it in two steps. First we wrapped the original gate in a software bridge: an agent on site maintained its list of numbers and read events back out of it, so the application could work as if the gate were part of the system. It was a crutch, though, dependent on someone else's hardware and its interface.
The second step is our own unit. Into an IP-rated plastic enclosure we fitted a Raspberry Pi, an LTE modem, a relay for the barrier drive, two opto-isolated inputs for external triggers and a built-in 230 V power supply. Industrial connectors, a switched mains socket, the open button and two LTE antennas lead out of it. We mark out, drill and populate the enclosure in our own workshop. The firmware runs as a system service that starts with the device. Diagnostics are visible without a laptop: the backlit button reports service start and error states by blinking, the dashboard opens from the local network, and the application sees the unit's state as well. Hardware and firmware are both ours — from the choice of relay to the format of the log.
Key features
- gate opening by missed call from an allowed number over the unit's own LTE modem
- whitelist synchronized from the application — no editing over SMS
- opening by the button on the enclosure, by application command or external contact
- two opto-isolated inputs: entrance camera, the original GSM gate, a switch
- opening log with trigger source and result, available for matching loads
- web dashboard: gate state, modem telemetry, SIM, network, service functions
- configurable relay timing including a guard pause against repeated switching
- diagnostics by blinking the backlit button — service start and error states
- remote restart of the service, the modem or the whole unit without a site visit
Results & benefits
- the list of allowed numbers is managed from the application, not over SMS and a serial cable
- the opening event is available at once and pairs with the weighing and the plate snapshot
- the barrier can be opened locally — by button or contact, independently of the network
- remote service: restarting the service, the modem or the unit without driving to the site
- hardware and firmware are ours — no more dependency on a closed device
