Skip to content
Contact

Client project · IoT · On-premises

Field-device data platform: Evaluated live. Kept in-house.

An IoT platform that does not run in someone else’s cloud but directly in the client’s own data centre. The devices report their readings over MQTT to a broker the client owns. A Laravel application evaluates them in real time and shows the service team which device needs attention.

Discuss a similar project The path of a reading

Key facts

Client
Measurement equipment manufacturer
Operation
On-premises, in the client’s own data centre
Technologies
  • Laravel
  • Livewire
  • MQTT broker
  • Redis
  • On-premises

Data flow

Schematic

Field devices

  • Device 01
  • Device 02
  • Device 03
  • Device 04

The client’s data centre

MQTT broker

receives the readings

Real-time evaluation

Laravel application

Alert for device 03

Service view

  • Device 01 normal
  • Device 02 normal
  • Device 03 needs attention
  • Device 04 normal

No data with third parties

Third-party cloud no data

Schematic: device numbers, messages and states are made up. They show the principle, not the client’s data or set-up.

The picture shows the path schematically. Field devices report their readings over MQTT to a broker the client owns, a Laravel application evaluates them in real time, and the service view marks the device that needs attention, here device 03. The platform runs in the client’s own data centre. The third-party cloud receives no data.

The project

From the field into the client’s own data centre. In real time.

elsyQ built the platform for a measurement equipment manufacturer. The result comes down to three points. What the terms behind them mean is explained further down the page.

The path of a reading

A reading on its way: from the field device to the service team.

MQTT decouples sender and receiver. A device sends its message to the broker, and the broker passes it on to every client with a matching subscription. The device does not need to know who is listening.

One reading, stop by stop

Example

  1. Device

    The device publishes

    The device sends a message to the broker. It carries a topic, which is a path made of levels, and the payload.

    Topic
    tenant-a/site-1/device-03/reading
    Payload
    {
    "device": "device-03",
    "value": 80.9
}

    MQTT does not prescribe a payload format. JSON is only an example here.

  2. Broker

    The broker distributes

    The broker compares the topic with its clients’ subscriptions and passes the message on to every client whose subscription matches.

    Subscription tenant-a/+/+/reading matches tenant-a/site-1/device-03/reading

  3. Laravel application

    The application evaluates

    The Laravel application evaluates the readings in real time. In this example a simple rule checks an upper limit.

    Example rule: alert above 80%, cleared only at 75% or below

    Reading 80.9% is above 80%.

  4. Laravel application

    An alert is raised

    In the example the value is above the limit. That turns into an alert for the service team, and it stays active until the value has dropped far enough.

    Device
    03
    Value
    80.9%
    Limit
    80%
    State
    active

  5. Service team

    The service team sees it

    The application shows the service team which device needs attention. A reading has turned into something a person can act on.

    Device 03 needs attention

Example: topic, payload, subscription and rule are made up. They show how a reading can travel over MQTT, not how the connections in the project are built.

MQTT in brief

Broker

The server every message passes through. Devices and applications connect to it, not directly to each other.

Publish and subscribe

Whoever sends publishes under a topic. Whoever wants to receive subscribes to topics. Sender and receiver do not need to know about each other.

Little overhead

MQTT was designed for devices with little computing power and for unreliable networks. The fixed header of a message takes only two to five bytes, and each client keeps a single connection to the broker.

Topics and subscriptions

Example

A topic is a path of levels separated by slashes. A subscription may contain wildcards. A + stands for exactly one level. A # may only come last and covers any number of levels from that point on, including none.

Structure of the example topic

  1. tenant-a Tenant
  2. site-1 Site
  3. device-03 Device
  4. reading Message type
Which example topics the three subscriptions match
Topic Filter 1 tenant-a/+/+/reading Filter 2 tenant-a/site-1/# Filter 3 +/+/device-03/#
tenant-a/site-1/device-01/reading matches matches does not match
tenant-a/site-1/device-03/reading matches matches matches
tenant-a/site-2/device-04/reading matches does not match does not match
tenant-a/site-1/device-03/status does not match matches matches
tenant-b/site-1/device-11/reading does not match does not match does not match
tenant-b/site-1/device-13/status does not match does not match does not match

The hierarchy is made up and only shows the principle. MQTT merely specifies that levels are separated by slashes; what they are called and in which order they come is up to each system.

Three levels of delivery

How reliably a message arrives is set in MQTT by its quality of service, QoS for short. More reliability costs more packets.

QoS 0

at most once

  1. PUBLISH

    from sender to receiver

Sent once, without acknowledgement. If the connection drops, the message can be lost.

QoS 1

at least once

  1. PUBLISH

    from sender to receiver

  2. PUBACK

    from receiver to sender

The sender keeps the message until PUBACK arrives and sends it again after a dropped connection. That is why it can arrive twice.

QoS 2

exactly once

  1. PUBLISH

    from sender to receiver

  2. PUBREC

    from receiver to sender

  3. PUBREL

    from sender to receiver

  4. PUBCOMP

    from receiver to sender

Four packets in two round trips. With PUBREC the receiver confirms receipt and remembers the packet identifier. With PUBREL the sender releases the message, and PUBCOMP completes the exchange. If a retry makes the message arrive twice, the receiver recognises it by its identifier and delivers it only once. It is the most expensive level.

The level applies per hop: from the publisher to the broker, and from the broker to each subscriber. A subscriber receives at most the level it subscribed with. Retries at QoS 1 and 2 only happen if the session outlives the dropped connection. All of this describes MQTT in general; this page does not say which levels the project uses.

Real-time evaluation and alerts

Evaluated live. An alert as soon as a device needs attention.

The Laravel application evaluates the readings in real time, and the service team gets alerts. The illustration below shows what an alert rule can look like, for example: an upper limit with hysteresis.

Why hysteresis

When a value hovers just around the limit, a simple rule keeps switching the alert on and off, and whoever handles the alerts gets one message after another. With hysteresis, an alert only ends once the value has dropped a fixed margin below the limit. A burst of alerts becomes a single one.

Four sample devices, one limit

Illustration · synthetic data

Alerts for the service team

  1. Device 03: alert since reading 82, peak 90.8%, still active

Limit 80%, hysteresis 5 percentage points. Alerts across all readings: 1, still active: 1.

Alerts across all readings for each limit, with and without hysteresis
Limit with hysteresis without hysteresis
70% 3 7
75% 3 5
80% 1 3
85% 1 8
90% 2 2

Four sample devices deliver 120 synthetic readings each. Device 03 starts rising at reading 61, crosses the limit of 80% at reading 82 and stays in alert until the end, peaking at 90.8%. Device 02 comes as close as 78.2% without crossing the limit. Alerts with hysteresis: 1, without hysteresis: 3.

Illustration with synthetic data: 120 readings per device, generated from a fixed formula. The limit rule is a teaching example, not the project’s alert logic.

In-house operation

Own data centre, own data, no one else’s cloud.

On-premises generally means that software runs on servers a company operates itself rather than with a cloud provider. That is how this platform runs: in the client’s own data centre.

What sits in-house

Schematic

In the field

Field devices reporting over MQTT

The client’s data centre

  • The client’s own MQTT broker
  • Laravel application with real-time evaluation
  • Readings and alerts
  • Roles, tenants and audit trail

Outside

Third-party cloud

no data

Schematic drawn from the project’s key facts, not a network diagram.

On-premises in general

Who decides

Whoever runs the servers decides where the data lives and who can reach it. The timing of every update is the operator’s call as well.

Who does the work

What a cloud provider would otherwise take care of sits with the operator: updates, backups, monitoring. That belongs in the plan from the start.

What it does not mean

On-premises does not mean sealed off. Devices in the field still have to reach the servers in the data centre, and that route needs planning.

These three points apply to on-premises operation in general. How the network and operations look in the project does not belong on a public page.

Roles, tenants, audit trail

Roles and tenants separate who sees what. The audit trail keeps the record.

The platform is role-based and multi-tenant, with an audit trail. What the three terms mean in general:

Role
Defines what a user may do, for example only view or also manage.
Tenant
A customer or unit whose data stays separate from everyone else’s within the same installation.
Audit trail
A record of who did what and when. Entries are usually only appended, never changed.

Same application, different view

Illustration · sample data
Devices by tenant
Device Tenant State
Device 01 Tenant A normal
Device 02 Tenant A normal
Device 03 Tenant A needs attention
Device 04 Tenant A normal
Device 11 Tenant B normal
Device 12 Tenant B normal
Device 13 Tenant B normal
Permissions by role
Permission Service Administration
View devices and readings allowed allowed
See alerts allowed allowed
Manage users and roles not allowed allowed
View the audit trail not allowed allowed

Audit trail

  1. No. 141 07:58 Tenant A Administration Assigned the Service role
  2. No. 142 08:03 Tenant A Service Signed in
  3. No. 87 08:11 Tenant B Service Signed in
  4. No. 143 08:17 Tenant A System Raised an alert for device 03
  5. No. 144 08:40 Tenant A Administration Changed the limit for device 02
  6. No. 88 08:52 Tenant B Administration Assigned the Service role

Illustration with made-up data. The roles and permissions are examples, not the project’s. Entries are numbered consecutively per tenant, so a missing number stands out at once.

Technology

Five building blocks, one platform. Each one explained briefly, and where the key facts say something about its use in the project, it is noted alongside.

Laravel

A PHP framework for web applications. Routing, database access, authentication and authorisation come with it.

In this project The Laravel application evaluates the readings in real time and shows the service team which device needs attention.

Livewire

A framework for Laravel that builds interactive interfaces from PHP components instead of a separate JavaScript front end. When something happens in the browser, the server re-renders the component and Livewire swaps in only the parts of the page that changed.

Part of the technology stack

MQTT broker

The server in the publish-subscribe protocol MQTT. It receives messages and distributes them to the clients that have subscribed to their topic.

In this project The broker the client owns, to which the devices report their readings.

Redis

A data store that keeps keys and data structures in memory and can additionally persist them to disk.

Part of the technology stack

On-premises

Software runs on servers the company operates itself, rather than with a cloud provider.

In this project The platform runs in the client’s own data centre, not in someone else’s cloud.

From the web interface to the firmware

Independently of this project, elsyQ builds the whole chain between web and hardware: web interface and API in Laravel, connection over MQTT or OPC UA, and the firmware on the device.

  1. Web interface and API

    Laravel

  2. Connection

    MQTT · OPC UA

  3. Firmware

    on the device

See all projects

Frequently asked questions

What is the field-device data platform?

The field-device data platform is a client project by elsyQ for a measurement equipment manufacturer: an IoT platform that does not run in someone else’s cloud but directly in the client’s own data centre. The devices report their readings over MQTT to a broker the client owns. A Laravel application evaluates them in real time and shows the service team which device needs attention.

What does on-premises mean for this platform?

The platform elsyQ built for a measurement equipment manufacturer runs in the client’s own data centre, not in a third-party cloud. It runs entirely in-house, and no data sits with third parties. In general, on-premises means that software runs on servers a company operates itself.

How do the readings get into the platform?

On the platform elsyQ built, the devices report their readings over MQTT to a broker the client owns. In general, MQTT works on the publish-subscribe principle: a device publishes a message under a topic, and the broker passes it on to the clients that have subscribed to that topic.

What is MQTT, and what does the broker do?

MQTT is a lightweight publish-subscribe protocol that elsyQ uses to connect devices to applications. Devices and applications do not talk to each other directly but through a broker, which receives messages and distributes them to subscribers by topic. How reliably a message arrives is set by the quality of service, from at most once to exactly once.

How does the service team know which device needs attention?

On the platform elsyQ built, a Laravel application evaluates the readings in real time and shows the service team which device needs attention. The service team also gets alerts. The rule with a limit and hysteresis on this page is an illustration with synthetic data, not the project’s alert logic.

What do role-based, multi-tenant and audit trail mean here?

The platform elsyQ built for a measurement equipment manufacturer is role-based and multi-tenant, with an audit trail. In general, roles define what a user may do. Tenants are customers or units whose data stays separate within the same installation. An audit trail records who did what and when.

Which technologies is the platform built with?

elsyQ built the platform with Laravel and Livewire, together with an MQTT broker and Redis. Everything runs on-premises, in the client’s own data centre. Laravel is a PHP framework for web applications, Livewire builds interactive interfaces on top of it from PHP components, and Redis is a data store that keeps its data in memory.

Does elsyQ build platforms like this for other devices too?

elsyQ builds device data platforms for other devices too. Independently of this project, elsyQ covers the whole chain between web and hardware: web interface and API in Laravel, connection over MQTT or OPC UA, and the firmware on the device. Whether a platform should run in your own data centre or in a cloud is something we settle with you at the start of the project.

Trademark notice Third-party names mentioned here (Laravel, Livewire, Redis, OPC UA) are marks of their respective owners and are used only to identify software or standards. elsyQ is not affiliated with these owners.

Work with us

Readings from your devices, evaluated where you want them?

Tell us which devices you have and what your service team needs to see. We will tell you how we would build it.

Discuss a similar project All projects