In the field
Sensors, actuators and machines. A microcontroller, for example an STM32 or an ESP32, reads the measurements and drives the outputs.
Guides · Embedded
How do you connect an embedded device to a web application or the cloud?
by Salvo De Luca, founder and CEO of Dialogicom · published 5 November 2026 · updated 6 November 2026
The device collects data and sends it, on its own or through a gateway, to a server that checks it, stores it and shows it in a web application. Along the way there are three choices to get right: how the device communicates, how the connection is protected and how the firmware is updated remotely.
The path of the data
From the field to the screen, in four stages.
The link
The data leaves: over cable, Wi-Fi or a mobile network, or first over a fieldbus to a gateway that takes it onto the network.
The server
It receives the messages, checks who sent them, stores the data and sends commands and settings back to the devices.
The application
Dashboards, history, alerts and, where useful, analysis with artificial intelligence, from a browser or an app.
New machines and existing ones
On its own, or through a gateway.
A new device can connect on its own: an ESP32, for example, has Wi-Fi on board. Machines that already exist, instead, usually talk over a fieldbus, a link designed to let boards and machines communicate. In these cases you add a gateway: a small device that speaks the bus on one side and the network on the other.
- CAN: a robust bus, born in vehicles, on which many control units exchange short messages over the same two wires.
- Modbus: a simple protocol, widespread in industrial plants, in which one device asks and the others answer.
- RS485: the electrical link Modbus often runs on, suited to long distances and electrically noisy environments.
The gateway is also the right place for a first pass on the data: filtering it, queuing it when the network is down, sending only changes instead of every reading.
The hardware
Microcontroller or FPGA.
To read sensors, switch a relay and talk to the network, a microcontroller is almost always enough. STM32 is a very large family, often chosen for control and precise timing. ESP32 chips have Wi-Fi and Bluetooth built in, which makes them handy for connected devices.
An FPGA is a chip whose logic you design yourself. It is needed when many things must happen at the same instant with very precise timing, for example processing fast signals. It is more flexible and more powerful at these tasks, but it costs more and calls for different skills. The two often live side by side in the same product.
Communication
How the device talks to the server.
Device and server have to agree on how they talk. Two common choices: HTTPS, the same protocol websites use, handy when the device sends data now and then; and MQTT, a lightweight protocol in which devices publish messages on topics and the server receives them, suited to many devices that stay connected. Whatever the choice, three rules apply:
- The device knows what to do when the network is down: it keeps the data and sends it later.
- Every message carries the time of the measurement and the identity of the device.
- The server does not trust data just because it arrives: it checks it, as it would a form filled in on a website.
Security
A connected device is a computer on a network.
And it often sits somewhere you do not control. The basic rules:
- Each device has its own identity and credentials, never one password shared by all.
- The connection is encrypted, and the device checks that it is talking to the right server.
- The device opens the connection to the server: it does not sit listening on the Internet.
- New firmware is installed only if it is signed by whoever produced it.
- Debug ports are closed on production devices.
No device is one hundred per cent secure. These rules reduce the risk and limit the damage if a device is tampered with.
Updates
Firmware, updated remotely.
A device in the field lives for years, and sooner or later its firmware needs updating: for a bug, a new feature, a security fix. Remote updates, often called OTA (over the air), avoid sending a technician on site. They must be designed carefully, because a failed update can stop a device that is far away.
- Two slots for the firmware: the new one is written next to the old, and if it does not start the device goes back to the previous version.
- Updates in batches: a few devices first, then the rest.
- The server knows which version runs on each device, and which ones are behind.
Our experience
Device and server, one project.
We have been designing electronics and firmware since the days of the Merlino and Singularity FPGA boards, and today we work with STM32, ESP32, FPGAs and with CAN, Modbus and RS485 buses, in sectors such as automotive, agriculture, industry and automation, logistics and regulated gaming machines. Much of this work is white-label: our customers put their name on it, and that is why we do not cite it.
On the software side we build the web and cloud applications that receive the data. We use MQTT and remote (OTA) updates in our projects. Having both parts in the same team avoids the most common problem in these projects: a device and a server each designed on its own, that only meet at the end.
Limits
What to know before you start.
- Networks in the field are less reliable than office ones: the system must work when the network is missing.
- Every extra device is one more device to look after: identity, updates, replacements.
- Connecting an existing machine depends on what it exposes: some give no access to their data without the manufacturer.
- Industry rules and certifications can constrain the choice of components and radios: check them at the start, not at the end.
Frequently asked questions
The questions we get on this topic.
Often yes, if they have a fieldbus or an output the data can be read from. You add a gateway that reads the bus and sends the data to the server, without touching the machine's logic.
It depends on where the device is. Cable is the most stable, Wi-Fi is handy inside a well-covered building, a mobile network is for devices that are far away or on the move. In every case the firmware must cope with periods without a network.
In the cloud or on a server of yours. The choice follows the same criteria as any web application: who looks after it, where the data must stay, how many devices are connected.
Yes, in two places: on the server, to analyse the collected data and flag anomalies, or on the device, with small models that decide without waiting for the network.
A device to connect?
Whether it is a new board or a machine that has been running for years, tell us what it has to do: we will propose the path from the field to the screen. We reply within 24 working hours.