On the device
Boot, agent, modules, security, field work.
In brief
This page describes what happens inside the machine, once installed at the customer's site.
The device boots on your brand's logo, connects, and puts itself right on its own. If there is no network, it boots anyway: being offline is a normal case, not a fault.
A program watches over it continuously: it announces the machine's state, applies what has changed, replays what did not get through. Nothing is lost, nothing is done twice.
And on site, a technician sets the network through a plain USB cable, with no network and no card rewriting.
What it brings : Your machines hold up on poorly connected sites, and an intervention needs neither network nor special equipment.
In detail
1. First boot
From power-on to the home screen, everything has to happen without a technician — and without a network if need be.
- A clean screen: the customer's logo, no system messages.
- Address and name displayed at boot, readable with no keyboard.
- Booting offline is a normal case: the agent waits ten seconds for the network, then starts.
- Firewall active before the applications, from the first second.
- Automatic enrolment: the device is created in its fleet, named, then deployed.
- Clean shutdown: writes are flushed, the card unmounted properly.
2. The agent
A program watches over the machine continuously. It announces its state, applies what has changed, and replays what did not get through.
- A heartbeat every minute: it sends the state up, it brings the configuration down.
- It never blocks: announcing and working happen in parallel.
- Convergence: it compares what is asked with what is applied, and acts only if they differ.
- A new attempt at each heartbeat, never giving up.
- Automatic rollback on failure, with the reason kept and reported.
- Self-repair of a module that is alive but stuck, with a guard against runaway loops.
- Agent update: two slots, a switch, and a return if the first heartbeat does not confirm.
- Actions never lost, never duplicated: replayed until acknowledged.
- Minimal writes: in steady state, the device writes nothing to its card.
3. Modules and the local bus
The device's applications talk to each other over a local bus. That is what makes it possible to add a function without touching the others.
- The bus starts first, then the modules in parallel.
- No module is called active before it answers.
- Mutual discovery: a module that starts late receives the latest states.
- Hardware is a list of "things": lock, sensor, reader, screen, terminal, coin mechanism.
- Independent drivers: the door sensor knows nothing of the lock.
- The simulator publishes the same list as a real driver — the same business code on both sides.
- The physics lives in the simulator: a door does not open if the lock is engaged, unless forced.
- Full-screen display: several outputs, rotation per screen, remote screen for diagnosis.
- Cloud synchronisation folder by folder, every quarter of an hour, with an urgent mode in seconds.
- Queryable logs by period, module, level or text.
4. Security on the device
A device installed at a customer's site is an exposed device. Three principles answer that.
- Private key never transmitted: it is baked into the image and does not leave the machine.
- Firewall closed by default: with no rule, everything inbound is refused.
- No secret in the configuration: access is time-limited and re-read live.
- Technician certificate validated with no network, by the device itself.
- Embedded console authenticated by cookie — never a token in the address.
- Outbound connection only: no port is opened on the device.
- Only declared ports are reachable, and the list comes from the cloud.
- Encrypted disk tied to the hardware: a stolen card stays unreadable.
5. On site
What lets a technician intervene with no network and no special equipment.
- A USB cable is enough: the device serves a local page to set WiFi, address and DNS.
- The laptop keeps its Internet access throughout.
- Each change is tested and rolled back if it breaks the link.
- Nothing to rewrite, and no network required to authenticate.
- Progressive network repair: reconnection, then a restart — never during a transaction.
- Hardware watchdog: a power-cycle restart if the system freezes completely.
- Replacing a card or a box: rewrite, plug in — identity and history follow.
6. The zone that serves the device
Devices only ever talk to their own zone, never directly to the platform's core. That is what makes dedicated hosting genuinely watertight.
- The zone holds no key: the blast radius is limited to a single device.
- The same computation everywhere: the configuration served in the zone is identical to the central one.
- In a dedicated zone, no real-time traffic passes through the vendor.
- A dedicated zone sees no identifier from the central database.
- Offline detected within three minutes, each transition becoming an alert.
- Interchangeable addresses: replacing an entry point in production requires no card rewriting.
7. The payment terminal
The third device type: no image, no card writing. The application carries the identity and the configuration exactly like the agent.
- Updated from the platform, like the configuration.
- On a locked terminal, the platform drives the manufacturer's application store.
- As a companion: it brings payment, badge reading and the screen to the box.
- Standalone: it becomes the machine's master.
- An emulator makes it possible to develop and demonstrate without physical hardware.
Its screens are described in Distrib — machine screens.