The equipment is out at the sites and you are in the office. We fit sensors to it, connect them to the internet and display the readings in one program that opens in a browser. If the temperature goes outside its limits, a door has been left open or the power has failed, the responsible employee gets a message immediately rather than finding out in the morning from the spoiled goods.
In plain terms: small devices are fitted to the equipment and continuously measure what matters — the temperature inside a cold room, whether a door is open, whether there is power, whether the compressor is running. Once a minute these measurements go over the internet to a server. You open a browser and see the state of every unit of equipment at every location.
IoT stands for the internet of things. The point is that instead of a person walking around with a notebook writing readings down, the equipment sends them to the software itself. Nothing has to be done for this: the data arrives on its own, around the clock, including nights and weekends.
The main difference from a simple screen of figures is that the system does not wait for somebody to look at it. It compares every measurement against the norm you set for that equipment. If the norm is breached, it finds the employee responsible for that site in the directory and sends the message to them.
An example. In a freezer room at the warehouse −18 °C is the permitted level. At 21:04 the sensor reports −16.8 °C. Nobody is looking at the screen at that moment. Fifteen minutes later the temperature is still rising — the system creates an event, records the room number, the warehouse address, the time and the current value in it, and sends a message to the warehouse duty officer. At 21:33 they arrive and find the vestibule door not properly closed. The goods are intact.
None of the equipment has to be replaced. The refrigerator, vending machine, pump or air handling unit stays where it is — what is added is what it does not have: sensors, a communication device and software in which the whole fleet is visible as a single list.
Every project starts with three questions: what can physically be measured on this equipment; how the data will leave the site and reach the internet; who is responsible for a deviation and how many minutes they have to respond. Until the third question has an answer, what you get is a nice screen of figures rather than a system that prevents anything.
| What is implemented | What it amounts to |
|---|---|
| The reading is shown on screen in real time | observation |
| The reading is stored in a history with an exact time | a foundation |
| Going outside the norm is recorded as a separate event | a foundation |
| The event has a specific employee and a response deadline | monitoring |
| The employee's response is recorded and closes the event | monitoring |
The line runs along two things: an event has a person and it has a deadline. A screen showing the current temperature saves nothing by itself — while nobody has been told to look into it, a deviation stays a line on a chart. That is why the norm, the responsible person, the response deadline and the closing mark are mandatory fields of the system rather than optional settings.
The limits of what is possible are set by the equipment, not by the software: only what it measures or what a sensor can measure can be read, and only what its controller permits can be changed. What is available on your model is established from the manufacturer's documentation during discovery.
The whole path a single measurement takes — from the device on the refrigerator to the message on a phone. Further down the page each of these six links is examined in more detail.
What is being watched: a cold room, a display case, a freezer, a vending machine, a pump, an air handling unit, a production line. Every unit is registered in the system as a separate card — what it is, which site it stands at, what its datasheet says and when it was last serviced.
The devices that measure. A sensor is a small device measuring one value: temperature, humidity, pressure, current, whether a door is open, whether there is voltage. A controller is the equipment's own brain: on some models it can report its readings and error codes to the outside, and then no extra sensors are needed. Where it cannot, we fit our own.
How the readings reach the internet. A small communication device is installed at the site: it collects the measurements from the sensors and sends them to the server over an internet cable, Wi-Fi or a SIM card. If the internet goes down, the measurements accumulate in its memory and go out when the connection returns. The device's own silence counts as an alarm too.
Where the data lives. A server is a computer in a secure data center running around the clock. Cloud means it does not stand in your office: there is nothing to buy, cool or service, and the software can be reached from anywhere. The server receives the measurements, stores them in the history, checks them against the norms and turns a deviation into an event.
The program you see. It opens in a browser on a computer or a phone with a login and password — nothing to install. On one screen: sites, equipment, current readings and the list of open deviations. Equipment of different makes all looks the same.
The outcome of the whole chain: a message to a specific employee, charts and logs for investigation, monthly reports and — where the controller permits it — changing the equipment's settings straight from the panel.
The measurement frequency and the permitted limits are set separately for every type of equipment rather than as one figure for the whole network. A freezer, a chilled display of ready meals and a warehouse cold room differ both in what temperature is normal and in how long it may be exceeded.
Refrigeration is the area where monitoring pays for itself fastest, because a breach of the regime is invisible to the eye. Nobody notices a door left ajar overnight, and by morning the decision has already been made for you.
An example. On a Friday evening the compressor in a freezer room fails. Overnight the goods thaw, on Saturday they are partly refrozen, and on Monday the batch is written off. With monitoring, the message about the failure arrives at 21:00 on Friday, and the matter ends with a call to the service company.
The equipment varies, too. A freezer and a chilled display of ready meals share neither the permitted temperature, nor the speed at which it is breached, nor the cost of an error. That is why the norm is set for each unit rather than once for the network — taking into account what is stored inside it.
What can be read from a refrigeration unit:
The set depends on the specific model. If the factory controller exposes values and error codes, the system reads them directly. If it does not, external sensors for temperature, door and power are fitted. What is available on your equipment is determined from its documentation during discovery rather than promised in advance.
That is why the norms are configured for the type of equipment and for the goods inside it. Without that, messages start arriving constantly, employees stop opening them — and the system runs for nothing.
The devices used across these groups are roughly the same. The difference lies in the permitted regime, in the cost of an error and in who the message goes to. The structure is identical throughout: a unit of equipment, a site, readings, norms, events, a responsible person.
A location with no shop assistant: there is simply nobody to notice that a door did not close or a unit has stopped. The equipment stands in an office, a factory or a coworking space, and an employee comes by every few days. Temperature and door monitoring here is the only way to learn about a problem in time.
Deep sub-zero temperatures and a large reserve of cold: a deviation develops slowly and is discovered through a whole batch being spoiled. What is monitored is the temperature, how long it stays outside the norm, compressor operation and defrosting.
On the sales floor the door is opened dozens of times a shift, so the regime is breached constantly. What matters is therefore not the excursion itself but how long it lasts and how often it repeats during the day.
A large volume with several zones at different temperatures: one measurement point does not describe the room. Several sensors are fitted, and the door and the power are monitored separately — a cold room stopping means losing the entire contents, not one shelf.
Several rooms and units at one site, working in shifts and around the clock. What is needed is a split of responsibility by zone, a long history and a report on compliance with the regime for a month or a quarter.
A chain of locations with identical equipment: dozens of display cases and chest freezers at different addresses. The value here is in comparison — where deviations repeat, which location systematically falls outside the regime, which unit is due for repair.
Storage of raw materials and finished products, where the regime is a requirement rather than a convenience. Besides the messages, provability is needed: a chart for every room over a period and records of who responded to deviations and how.
A separate group is made up of units whose controller was never designed to communicate outwards at all. They are connected with external sensors: temperature, door, power, current draw. There is less data than from a smart unit, but the essentials — the regime, the door, the power and the compressor — are visible, and such a unit sits in the common list alongside the rest.
Every reading lives in the system in two forms. The first is the value itself, which is simply stored in the history. The second is a rule: at what value and after how many minutes this becomes a deviation somebody has to be told about.
An example. A temperature of −16 °C in a freezer room is always stored, every minute. But a message goes out only if it stays above −18 °C for more than fifteen minutes in a row.
The full list of what is read and monitored:
Loss of connection is not a trifle but a full-blown alarm. A silent device does not mean no data but we know nothing about this site. The temperature there may be within the norm, or it may have been rising for an hour. That is why a loss of connection creates the same kind of event as a temperature alarm instead of leaving a gap in the chart.
There are four levels, and the level determines who the system disturbs and how:
Every site in the system has a responsible employee, and every event type has its own delivery rule. The system does not send everything to everyone: it looks at which site the deviation is at, what type it is and what time it is, and picks the addressee by that rule.
If an employee has not accepted an event within the allotted time, it automatically goes to the next person in the chain. At night, at weekends and on public holidays the addressee may be different — that too is configured in advance.
The type, the equipment and the site, the start and end times, the readings at the moment it arose, who the message went to and when, who accepted it, what they did and how it ended. That is enough to investigate a case from records a month later rather than from what the shift remembers.
| Condition | Hold time | Event |
|---|---|---|
| Temperature above the upper limit of the regime | 15 min | warning |
| Temperature above the limit | 45 min | alarm |
| Door open continuously | 5 min | warning |
| Temperature rising with the door closed | 10 min | alarm |
| No voltage at the equipment | 1 min | alarm |
| The controller returned an error code | immediately | alarm |
| The device is not checking in | 20 min | alarm |
| The compressor ran longer than usual over 24 hours | 24 hours | for servicing |
A screen from the system; the values are illustrative. The hold time column is how long the system waits before raising an alarm. Without it, loading goods, a normal defrost and cleaning the sales floor would produce a stream of false alarms, after which the messages stop being read.
Every case follows the same path: something changed on the equipment → the system recorded it as an event → a specific employee received a message. The only differences are the cause and who it is addressed to.
What happens: the sensor reported that the door was opened and, for longer than permitted, has not reported it being closed. What the system does: creates a door open longer than the norm event with the equipment number, the site address and the start time. Who finds out: the employee at the location — the message shows how long the door has already been open. The event will not close until the door is closed.
What happens: the measurements show a steady rise while the door is closed. What the system does: records the deviation with the current value and the rate of rise. Who finds out: the person responsible for the site receives a warning — the goods are still fine and there is time to respond. If the rise continues, the warning becomes an alarm and goes to several employees.
What happens: the device has been silent for longer than the permitted interval. What the system does: creates an alarm — not no data but an alarm: what is happening at the site is unknown. Who finds out: the same employees as for a temperature alarm, because the consequences can be the same.
What happens: the equipment returns a fault code itself. What the system does: records the code as it is and decodes it from the documentation for that model. Who finds out: the error appears on the equipment card together with the history — how many times the same code has already come from this unit.
What happens: the signs that defrosting is needed — a controller signal, running hours or the shape of the temperature cycle — go outside the norm. What the system does: creates a task rather than an alarm. Who finds out: the responsible employee — the task states what equipment it is, at which site and by when.
What happens: there is no voltage at the equipment. What the system does: creates an alarm with the exact time of the failure; the temperature keeps being recorded while the communication device runs on its own battery. Who finds out: the message goes out immediately — it is what the decision to move the goods out is based on, rather than when to call for a repair.
A screen from the system; the figures are illustrative. What matters here is not the message but the last line: the reason and the duration go into this room's history. If vestibule door not properly closed happens three more times in a month, it will show up in a report rather than being forgotten along with the shift.
The system is needed wherever equipment runs without constant supervision and a failure is noticed through its consequences. The set of readings and the cost of an error change — the structure of the system stays the same.
If at least three of the five points match your situation, the payback can be calculated from the specific losses you have already had in past periods — written-off goods, downtime, wasted call-outs.
Vending and micro markets: the telemetry module, the software on the device and the collection of events — sales, mechanism errors, temperature, door openings, the state of the payment modules and of the connection — were built by us and are described in the section on self-service systems page. The other areas in the list are the same scheme applied to a different type of equipment.
A real fleet is almost never uniform. At one site there are units of different years and different manufacturers: some have a controller that can pass data outwards; others have a controller that cannot talk; and others have nothing beyond the power section.
Hence the usual picture: four programs for four types of equipment, each with its own login, its own state labels and its own notifications. None of them gives an overall picture of the site, and comparing two units of different makes with each other is impossible altogether.
What we do in such a situation:
What we do not state in advance. We do not claim support for specific equipment brands and industrial protocols before discovery. The list of what can be read and what can be controlled is the result of working with your fleet's documentation and verifying it on site, not a line in a presentation. The one thing backed by finished development is the vending layer: our own telemetry module with MDB and EVA-DTS drivers, described in the section on self-service systems page.
Changing equipment settings from a browser is not always possible. That is a property of the equipment rather than of the software, and there are three cases:
This cannot be worked around in software. That is why we name the list of available commands after discovery, not before it.
The mix of makes is resolved not on site but inside the software: a translator is written for every type of equipment, and from there everything is identical. That is why a new type is connected by writing one module rather than by rebuilding the panel, the rules and the reports.
Controllers able to pass data outwards; controllers without that ability; external sensors; communication devices. Each has its own format, its own units of measure, its own state labels and its own reporting frequency.
A separate module is written for every type of source: it knows how to take data from that one specifically and converts it into a single internal format. The equipment is not changed — the software adapts. Such a module is called an adapter.
Identical units of measure, one list of states, an identical description of an event. After that a cold room and a pump are described in the same language, and the norm rules are written once for everything rather than separately for every make.
One screen for the whole fleet: sites, equipment, readings, open deviations, history, reports and available commands. An employee works in one program instead of switching between four.
| Data source | What can be read | Control | State |
|---|---|---|---|
| A controller able to pass data outwards | values, modes, error codes | partly, per the documentation | online |
| A controller that exposes nothing | through external sensors | no | online |
| External sensors on a communication device | temperature, door, power, current | no | warning |
| A vending telemetry module | sales, mechanism errors, temperature, door | yes | offline |
A screen from the system; the make-up is illustrative. In the panel all four rows look the same — the only difference remains in the what can be read and control columns, that is, in what the source physically allows. Whether control exists is decided by the equipment's controller, not by the software.
The panel opens in a browser with a login and password — like an ordinary website. There is nothing to install, and it works from a phone as well.
The first screen. Counters at the top: how many devices are online right now, how many are silent, how many deviations are open at this moment. Below is the list of sites, with their equipment under each one; every unit has a color-coded state (normal, warning, alarm, offline) and its current value.
The equipment card opens on a click on any unit. It brings together everything known about that refrigerator or unit:
The settings are made once and work by themselves from then on: norms and hold times by type of equipment; responsible people and message delivery rules by site, event type and time of day; employee roles — who sees what and who can do what; groups and filters by site, region and equipment type.
Why the history is kept. It is every measurement and every event, stored with an exact time and available at any moment. It is needed for five things:
A separate word about charts: they are there for investigation, not for reporting. When door openings, compressor starts and power failures are marked on the temperature line, the cause of a deviation reads immediately — there is no need to line up four different screens.
If the controller does not accept commands, the control section simply does not appear on the card. There is no dead button there — so that the shift never gets the impression that the equipment can be controlled from here.
At a single site with five refrigerators any approach will do, even a notebook. The difference starts at fifty units and at five hundred: the list stops fitting on a screen, the messages merge into a stream, and the employee responsible for everything stops being responsible for anything specific.
An example. At night the power is cut at one of the locations. Without configuration the system would send thirty separate alarms — one per unit of equipment — and everything else would be lost in that stream. With configuration, one message arrives: this site, power lost, 30 units affected.
What changes as the fleet grows:
A screen from the system; the figures are illustrative. The order of the numbers is not accidental: what comes first is not the size of the fleet but how many sites are currently unobserved. Six silent devices are six locations about which nothing is known.
Reports export to a file and can be built automatically on a schedule — on the first of every month, for example. For the refrigeration layer such a report doubles as proof of storage conditions for the period.
Rights are granted along the same structure: a location employee sees only their own equipment, a department head sees every site of their type, a dispatcher sees the summary across the whole network. Viewing, accepting an event and remote control are separated rather than granted as one bundle.
Sensors and controllers
Transmission to the cloud
A single panel
Messages and reports
The system's core work is built on simple rules: this value for longer than this many minutes = this message to this person. That is enough to cover emergencies, and it is where every adoption starts.
Once months of history have accumulated, data analysis can be added on top of it. It looks not for a limit being breached but for a change in the habitual behavior of a specific unit of equipment.
An example. A compressor usually reaches its operating mode in eight minutes. For the past three weeks it has needed twelve. No limit has been breached and no message would have been sent under the rules — but the unit is clearly heading for a failure, and it is better serviced before it stops on a weekend.
We state the boundary plainly. Failure prediction is something that becomes possible on accumulated data rather than a feature that works from day one. It needs a history not only of readings but of the failures themselves: without real cases there is nothing to train a model on. That is why in a project it is a separate stage after data collection has run for a period, rather than an item in the first release.
A related area is adopting artificial intelligence in business processes, where the same approach is applied to data from orders, enquiries and documents.
None of this replaces the alarm rules: rules react within minutes, analysis works on a horizon of weeks. Both layers are needed, and they are adopted in exactly that order.
The stages come in exactly this order. Skipping discovery is the most common reason a system ends up built around equipment that does not expose the data it needs.
A fleet inventory: models, controllers, documentation, what can physically be read from each unit, whether the sites have internet. The output is a list of what is available straight away and what will have to be covered by external sensors.
One site and a few units of equipment: installation, verification of the exchange on a live controller, tuning of the norms and hold times against how the equipment actually behaves rather than against the documentation.
Who is responsible for which sites, which events go to whom, what counts as an alarm and what is merely a note. Escalation and the merging of identical events are configured here as well; otherwise the stream of messages will devalue the system within a month.
The remaining sites follow the proven pattern, and new equipment types come as separate exchange modules. From there the history accumulates, and period reports and data analysis appear.
Tell us what equipment is installed at your sites, how much of it there is and which problems you currently learn about only through their consequences. We will tell you what can actually be read from it, where external sensors will be needed and where it makes sense to start the pilot.
