VMTech
Discuss a project →
← All capabilities
SYSTEMS & INTEGRATIONS · 06

Smart devices / IoT

A sensor on its own is useless: it shows a number. The value appears when an out-of-range reading becomes a task with an owner, and the history answers “when did this start”.

Discuss a project
THE READING'S PATH

What happens between the sensor and a person

Six steps: at each one data is lost or distorted if left to chance.

iot.vmtech.rs
Sensor: cold room
LIVE
in the history
Measurement +4.2 °C
Transmission connected
Sanity check value accepted
Out of range +8.1 °C · 12 min
A task for the owner assigned
History and report in the history
THE READING'S PATH
  1. MeasurementThe device takes a reading on schedule — the frequency fits the task rather than the maximum
  2. TransmissionData goes to the server; if the link drops the device buffers readings and sends them later
  3. Sanity checkImplausible readings are discarded so a faulty sensor does not raise a false alarm
  4. Out of rangeThe threshold fires on a sustained deviation rather than a single sample — fewer false alarms
  5. A task for the ownerThe alert reaches the person who can fix it and becomes a task with a deadline
  6. History and reportYou can see when the deviation began, how long it lasted and whether it repeats monthly
A FAMILIAR PICTURE

Why the sensors are installed but useless

Equipment on its own

  • Readings exist only on the device's screen and nobody records them
  • Every manufacturer has its own app and there is no combined picture
  • Alerts go to one person's phone, and that person is on holiday
  • Alarms fire on every spike, so the notifications have long been ignored
  • There is no answer to “when did it start”: no history exists

Once the data is in a system

  • Readings are stored with history, so you see the trend rather than only the current value
  • Devices from different makers are brought into one interface
  • The alert follows a rule: to whom, at what hour and what to do next
  • Thresholds account for how long a deviation lasts, so alarms are trusted again
  • The history answers an inspector's questions and lets you argue with a supplier from facts
SCOPE OF WORK

What the project includes

Reviewing the task

What needs measuring, at what precision, and which decision the result drives.

Choosing the hardware

Sensors and gateways for the site's conditions: power, connectivity, temperature, accuracy.

Data collection

Receiving readings, buffering during outages and protection against duplicates on resend.

History storage

A time-series store with sensible detail: recent data in full, older data averaged.

Alert rules

Thresholds that consider duration, different recipients by time of day and an escalation path.

Monitoring board

Current state of each site, charts over time and a list of active deviations.

Links to processes

A deviation creates a task, a request or a log entry — not just a chat notification.

Maintenance

Watching connectivity and battery levels, replacing failed units, firmware updates.

TECHNOLOGY LANDSCAPE

What the setup is made of

Sensors and gatewaysTemperature, humidity, door state, motion, consumption — matched to the site
Exchange protocolsMQTT or HTTP depending on the device and the connectivity on site
BufferingReadings accumulate during an outage and are resent without duplicates
Time-series storageHistory with older data thinned out, so the database does not grow forever
Rules engineThresholds, duration, schedules and escalation — configurable without rewriting code
Device monitoringA silent sensor is an event too: it is reported rather than waiting to be noticed

The hardware is bought and owned by your company. We do not tie the data to a platform of ours: readings live in your database and can be exported at any time.

QUESTIONS

What people usually ask

We already have sensors with the maker's app. Why add anything?

If there are few sites and the app is adequate, there is no reason — and we will say so. It starts to matter when there are several device types, when you need one combined picture, years of history, or a link to processes: so a deviation creates a task rather than just a phone notification.

What if the site loses its internet connection?

The device or gateway buffers the readings and sends them when the link returns — the history does not break. A separate alarm covers the silence itself: if data stops arriving, that is an event to be told about rather than to discover a week later.

What does it cost and who buys what?

Your company buys and owns the hardware — we help choose models suited to the site rather than reselling. Our part is collection, storage, rules and the interface; its cost depends on the number of sites and the complexity of the alerting scenarios.

Can we control the equipment, not just watch it?

Technically yes, but we approach it carefully: remote control needs protection against mistaken commands and clear limits. We usually start with monitoring and alerts — at that stage it often turns out the problem is solved by a procedure rather than automation.

Does the data stay with us?

Yes. Readings live in your database on your server, and export is available at any time. We deliberately avoid a design where the measurement history sits in someone else's cloud and disappears with the subscription — for reporting and supplier disputes it is the unbroken history that matters.

Related capabilities

Business automation A deviation becomes a task API integrations Links to the books and the CRM Server maintenance Where the data lives Custom development When you need your own interface

Let’s apply this capability to your project

We define the challenge, dependencies and a realistic delivery plan.

Discuss a project