Distrib — machine screens
The fridge, the bar, the vending machine, the technician application and the terminal.
In brief
Here is what the three people who approach a machine see: the customer, the delivery driver, the technician.
The customer badges in, the door opens, and the receipt builds up before their eyes as they help themselves. On a drinks bar, they choose their water, their flavouring and their size, and pay only for the volume actually served.
The driver badges in too: the machine offers restocking, removal or stocktaking, and they move from one to the next without badging again.
The technician has a separate screen, protected by a code, to test the hardware and connect the machine.
What it brings : The experience in front of the machine stays simple, and an intervention needs no external tool.
In detail
The principle common to every machine screen: the screen is a stateless view. The state of the sale lives in the selling agent and is published on the local bus; the screen renders what that state implies and returns intentions — cancel, choose, change language. A reload rebuilds everything in under a second, and one screen, two screens or a terminal all show the same truth. The language is shared by every display at the point of sale.
The self-service fridge
| Screen | What you see | What you do |
|---|---|---|
| Unavailable | "No menu", "point of sale not configured" or "configuration revoked". | Nothing: no sale is possible. |
| Idle | "Present your badge", with the last receipt to unfold. | Badge, card or visual code. |
| Choice of operation (driver, technician) | "Hello {first name}, what would you like to do?" and three large buttons: restock, removal, stocktaking. If there are several offers, the choice of the assortment to put in place — the one already in place being marked. | Chain several operations without badging again, then finish. |
| Authorised | "Door unlocked" and the opening countdown. | Open, or cancel. |
| Open | "Help yourself" and the receipt building live: lines, discounts, total, VAT. A warning appears in the last minute. | Take, put back. |
| Warning | "Close the door", with automatic closing announced — the basket is kept. | Close it. |
| Awaiting detection | "Thank you, calculating". | — |
| Thank you | "Thank you {first name}" and the final receipt, or "nothing taken", or "restock recorded". The note "offline" appears if settlement happened in degraded mode. | Touch to finish. |
| Intrusion | A door opened without authorisation: the incident is logged and the missing products listed. | — |
| Refusal | The business message in large type, the four-digit code to enter on the consumer site to attach the badge, and the error code in small print. | Walk away, or attach the badge. |
| Field entry | Location, batch number, expiry date. | Enter or skip — never blocking. |
A permanent footer carries the customer's brand, the offer number and the "bus offline" and "cloud offline" indicators. The screen saver and the marketing content are published from the portal, and the machine runs the same module whether it is wired to real hardware or to the simulator.
The drinks bar and recipe machines
The selling screen
- Four choices, in large buttons: the water, the flavouring, the strength and the size.
- The size shows its volume and its price.
- What is missing is greyed out with its reason: an empty pouch removes its flavouring.
- Nutritional values recompute at each choice, then a large "serve" button shows the price, or "free".
- Pouring: a progress bar, the volume served against the target, and a stop button.
- Done: the volume and the price actually charged — the note "partial" appears if it was stopped early — along with the bottle avoided and the carbon saved.
The service screen
Opened with an operator code, in four tabs: consumables (level, alert and unavailability thresholds, "replaced" button), the menu (active or withdrawn recipes with their reason, publication identifier, price grid), the languages — the switch is immediate and shared — and payment: the accepted means and the terminal's state.
The maintenance screen
Opened with a technician code, also in four tabs:
- Diagnostics: bus, cloud and terminal tests, measured flow rate, and manual actuation of each water line and each pump.
- Calibration: the flow reading used to set the pulses per litre in the portal.
- Errors: the alerts in progress with their start time — leak, no flow, gas or pouch low or empty.
- About: the menu's publication identifier, the agent and screen versions, the device and the wired lines.
The code pad opens through the physical service button or a key combination on the footer. The footer itself stays visible at all times: brand, menu number, bus and cloud state, running on battery, bottles avoided and last pour.
The coffee machine
The same model: a menu of drinks and extras, a confirmed preparation cycle, consumables that grey out drinks and maintenance counters. It is served by the machine's screen or by the connected Android terminal.
The vending machine
Selection happens by code or on screen, with the price shown and payment by card, cash, badge or account. The sale is confirmed by the drop: a product that is not delivered is refunded automatically, with its message, and the faulty location is disabled and flagged. The field session is identical to the fridge's.
The technician application
It is served by the machine itself on the local network — the port is closed by default and opens through a firewall rule — and shows on the machine's screen for as long as it is unbound. It works offline, in the point of sale's languages.
- Pairing: the current mode, then the state of the binding.
- A pending reference is kept on the device and reported at the first network connection.
- Or a choice of point of sale from the list of free identities of the right type.
- The last decision is shown with its reason.
- Factory tests: one test per connected piece of hardware.
- Lines, pumps, sensors, screen, reader, terminal, network, with their live value.
- With no selling effect whatsoever.
- Call tests: the zone's reachability, the cloud key's validity, the last heartbeat and the clock.
- Network: the state, the link to the agent's local interface, the local logs and restarting a module.
The Android payment terminal
A single application, two roles set by configuration.
As companion to an embedded box
The terminal connects to the local bus and publishes three "things": payment terminal, badge reader and display. The selling agent talks to it exactly as it does to the simulator or the certified terminal.
- Selling screen: the brand, and the lines sent by the machine in large type.
- A band gives the payment status: present your card, accepted, made, refused.
- Brightness is driven by the machine.
- Diagnostics: the version, the core's state, the bus connection and the terminal's state.
- Demonstration panel: simulated badge, card accepted, card refused, no card — the same gestures being scriptable without a screen.
Standalone, when the terminal is the point of sale
The terminal then embeds the selling agent and the machine's driver: it becomes its master — it authorises the drink, reads counters and faults — takes payment by card, contactless, badge or visual code, displays the journeys, and reports sales, consumables and faults.
It has the full Fleet foundation: device identity, heartbeat, cloud channel, configuration convergence, monitoring, immediate cut-off and application updates from the platform — on a terminal locked by its manufacturer, the platform drives that manufacturer's application store.
Payment
It goes through the acquirer's application present on the terminal, and through its cloud interface for remote orders: pre-authorisation, partial capture by volume or by the amount actually due, cancellation, refund, and digital meal vouchers.
Developing and demonstrating without hardware
The workstation is a device of the fleet: the same composition runs locally, the machine's screen opens in a browser, and the simulator plays every thing — badge, door, hand, weight, flow, levels, network, card — from a generic interface, the same one for the fridge, the bar and the fountain. A scenario such as a forced door, a network outage or a refused card is played on demand, and production connects to real hardware through a simple configuration change.