DEV Community: Promeraki IoT

MQTT to ThingsBoard Setting Up Device Telemetry from Scratch

Promeraki IoT — Fri, 26 Jun 2026 12:30:11 +0000

ThingsBoard is one of the most capable open-source IoT platforms out there. But the first time you try to get a device publishing telemetry over MQTT, the documentation sends you in three different directions of device profiles, transport configurations, topic formats, and credential types. There are a lot of setups before you see a single data point on a dashboard.

This post cuts through that. By the end, you will have a device sending live sensor data to ThingsBoard over MQTT and seeing it in the Latest Telemetry tab. No fluff, just working code.

What You Need Before Starting

A running ThingsBoard instance, Community Edition, is fine. You can use the live demo for a quick look, though a local Docker setup is more reliable for following along since the demo instance has usage limits. You also need mosquitto-clients installed for quick command-line testing and Python 3 with paho-mqtt for the scripting part.

# Install mosquitto client tools

sudo apt install mosquitto-clients

# Install Python MQTT client

pip install paho-mqtt

Step 1: Create a Device and Grab the Access Token

In the ThingsBoard UI, go to Entities → Devices and click the + button to add a new device. Name it something like sensor-01. Once created, click on the device and copy the access token from the credentials tab.

This token is your MQTT username. No password needed. ThingsBoard uses it to identify which device is sending data.

Step 2: Send Your First Telemetry via Command Line

Before writing any code, test the connection with mosquitto_pub. This tells you immediately whether the setup works.

mosquitto_pub -d -q 1 \

  -h "YOUR_THINGSBOARD_HOST" \

  -p 1883 \

  -t "v1/devices/me/telemetry" \

  -u "YOUR_ACCESS_TOKEN" \

  -m '{"temperature": 25.4, "humidity": 62}'

If you are running ThingsBoard 3.5 or later, you can use the shorter topic format:

mosquitto_pub -d -q 1 \ 

  -h "YOUR_THINGSBOARD_HOST" \ 

  -p 1883 \ 

  -t "v2/t" \ 

  -u "YOUR_ACCESS_TOKEN" \ 

  -m '{"temperature": 25.4, "humidity": 62}'

Both do the same thing. v2/t just saves bandwidth, useful when your device is on a metered cellular connection.

Now go to Entities → Devices → sensor-01 → Latest Telemetry. You should see temperature and humidity with the values you just sent.

Step 3: Continuous Telemetry with Python

A one-shot of publishing proves the connection works. For continuous monitoring, here is a Python script that simulates a sensor publishing every five seconds:

import paho.mqtt.client as mqtt

import json

import time

import random

THINGSBOARD_HOST = "YOUR_THINGSBOARD_HOST"

ACCESS_TOKEN = "YOUR_ACCESS_TOKEN"

TELEMETRY_TOPIC = "v2/t"

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)

client.username_pw_set(ACCESS_TOKEN)

client.connect(THINGSBOARD_HOST, 1883, 60)

client.loop_start()

try:

    while True:

        payload = {

            "temperature": round(random.uniform(20.0, 35.0), 1),

            "humidity": round(random.uniform(40.0, 80.0), 1)

        }

        client.publish(TELEMETRY_TOPIC, json.dumps(payload), qos=1)

        print(f"Published: {payload}")

        time.sleep(5)

except KeyboardInterrupt:

    client.loop_stop()

    client.disconnect()

Run the script, open the Latest Telemetry tab in ThingsBoard, and watch the values update in real time.

Step 4: Adding Timestamps from the Device

By default, ThingsBoard uses the server to receive time as the timestamp. If your device has a reliable clock and you want exact measurement times, include a ts field in milliseconds:

payload = {

    "ts": int(time.time() * 1000),

    "values": {

        "temperature": 24.8,

        "humidity": 55.3

    }

}

This matters when devices batch data offline and upload it later without client-side timestamps; every reading looks like it arrived at the same moment.

What Comes Next

Once telemetry is flowing, the next steps are setting up rule chains to route data, trigger alerts, and create automation workflows. Then building a dashboard to visualize the data beyond the raw latest telemetry tab. That is where ThingsBoard gets really powerful, but it all starts with getting MQTT telemetry in the door first.

For teams that need help going beyond the basics, custom widgets, multi-tenant architectures, or production-grade ThingsBoard deployments, Promeraki's ThingsBoard development team works with this stack daily.

Running ThingsBoard in production? What tripped you most during the initial MQTT setup authentication, topic structure, or something else entirely?

How Data Moves in a Connected Factory: From Sensor to Dashboard

Promeraki IoT — Mon, 22 Jun 2026 11:36:01 +0000

Industry 4.0 gets talked about like it is one big thing. In practice, it is a data pipeline. Sensors generate readings. Gateways process them. Cloud platforms store and analyze them. Dashboards surface them. Automation acts on them.

If you are building the software layer for any of this, what matters is understanding how data flows through each stage because that is where the architecture decisions live.

The Six Stages of Factory Data Flow

1. Data Collection

Everything starts at the machine. Sensors capture temperature, vibration, pressure, runtime, energy consumption, cycle time, and production count. PLCs and industrial controllers share machine-level state.

A vibration sensor on a motor picks up early signs of bearing wear weeks before a human notices anything. An energy meter flags that one machine is drawing 30% more power than the identical unit next to it. This is raw operational data with high volume, high frequency, and mostly useless until it moves somewhere it can be processed.

2. Connectivity

Data needs to leave the machine and enter a digital system. This is where protocol selection matters.

Machine-level → Modbus, OPC UA, Profinet
Lightweight IoT → MQTT (pub/sub over TCP)
Long-range → LoRaWAN, NB-IoT
Factory network → Ethernet/IP, Wi-Fi, 5G

MQTT handles most cloud-bound telemetry. OPC UA handles machine-to-machine interoperability. Modbus is still everywhere in legacy equipment. Most factories run at least two protocols simultaneously because the equipment spans decades of technology.

3. Edge Processing

Not everything needs to travel to the cloud. Latency-sensitive decisions happen at the edge.

An edge gateway sitting next to a production line filters noise, aggregates readings, and triggers local actions. If a motor's temperature crosses a safety threshold, the edge system reacts in milliseconds; it does not wait for a round trip to a cloud server.

if sensor_reading["temperature"] > SAFETY_THRESHOLD:
   trigger_local_alert("motor_01", "overheating")
   send_to_cloud(sensor_reading)
else: 
   aggregate_and_batch(sensor_reading)  # send every 60s

Edge processing also reduces cloud costs. Instead of streaming every raw reading at one-second intervals, the edge batches and compresses, sending summaries rather than firehoses.

4. Cloud Platform

The cloud handles storage, historical analysis, cross-site comparison, and heavy computation.

Time-series databases store machine telemetry. Analytics engines run trend analysis. AI models trained on historical data predict failures before they happen. Multi-plant manufacturers use the cloud layer to compare OEE (Overall Equipment Effectiveness), downtime, and energy usage across locations from a single view.

This is also where factory data connects outward into ERP, MES, maintenance systems, and mobile applications.

5. Dashboards and Alerts

Dashboards turn data into decisions. Operators see live machine status. Maintenance teams see equipment health trends. Plant managers track OEE, downtime, and energy across shifts.

Alerts make it actionable. A vibration spike triggers maintenance notifications. An energy anomaly flags a possible fault. A quality deviation pauses the line for inspection.

The difference between a factory that reacts to breakdowns and one that prevents them is usually this layer at the speed at which the right person sees the right data.

6. Automation and Workflow Actions

The final stage closes the loop. When conditions are met, the system acts without waiting for a human.

Create a maintenance ticket automatically. Notify the supervisor. Adjust process parameters. Stop a machine when safety limits are breached. Update ERP records. Send shift reports to plant managers.

This is where Industry 4.0 stops being a monitoring project and starts being an operational system.

Why the Architecture Matters More Than the Buzzword

Industry 4.0 is a label. What matters is the data pipeline underneath it how reliably data moves from machine to cloud, how fast the edge responds, how well your protocols handle legacy equipment alongside modern sensors, and whether your automation layer can act on what the data reveals.

Get the pipeline right, and the buzzword takes care of itself.

This post focused on the data pipeline, one piece of the industry 4.0 picture. For the full breakdown covering core technologies, real-world use cases, and a practical implementation roadmap, the Industry 4.0 and IoT guide on Promeraki covers the complete picture.

What does your factory data pipeline look like, and which stage gave you the most trouble to get, right?

Compare MQTT, CoAP, and HTTP for IoT applications. Learn when to use each protocol based on power, bandwidth, latency, and device requirements.

Promeraki IoT — Fri, 05 Jun 2026 12:40:57 +0000

Promeraki IoT for Promeraki Developments

Jun 5

MQTT, CoAP, or HTTP: Which IoT Protocol Fits Your Product?

#iot #mqtt #iotprotocols

3 min read

MQTT, CoAP, or HTTP: Which IoT Protocol Fits Your Product?

Promeraki IoT — Fri, 05 Jun 2026 12:40:13 +0000

There are more IoT protocols out there than most teams will ever need. That sounds overwhelming until you realize most connected products only use two or three; one for local communication, one for cloud connectivity, and sometimes one for device management.

The problem is not the number of options. The problem is that the protocol you pick at the design stage gets baked into your firmware, your cloud pipeline, and your data model. Change it later and you are rewriting half of your stack.

Here is a practical breakdown of the protocols that matter for most developers building connected products today.

The Three Layers You Are Choosing Across

IoT protocols sit in three distinct layers, and you typically pick one from each:

Application Layer → MQTT, CoAP, HTTP, AMQP (how data reaches your cloud)

Network Layer → LoRaWAN, NB-IoT, LTE-M, Wi-Fi, BLE (how data travels physically)

Industrial Layer → Modbus, OPC UA, Profinet (machine-to-machine on the factory floor)

A soil moisture sensor on a farm might use LoRaWAN at the network layer to push data 10 kilometers to a gateway and MQTT at the application layer to deliver that data to a cloud dashboard. Two protocols, two layers, one product.

The Big Three for Cloud Connectivity

MQTT - The Default for a Reason

Publish-subscribe model. Lightweight. Three QoS levels for delivery guarantees. Run over TCP with TLS encryption. Roughly 70% of cloud-connected IoT deployments use MQTT today.

A basic publish looks like this:

import paho.mqtt.client as mqtt

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)

client.tls_set()

client.connect("broker.example.com", 8883)

client.publish("sensors/temperature", '{"value": 23.5, "unit": "C"}')

Use when: You need real-time telemetry, bidirectional device control, or guaranteed message delivery across unreliable networks.

HTTP - Not for Telemetry, But Still Essential

Too heavy for continuous sensor data. But it is the standard for OTA firmware updates, cloud API integrations, and management dashboards. Every cloud platform supports it natively. Every developer already knows it.

Use when: Firmware updates, one-time configuration calls, or anything involving a browser.

The Wireless Layer - Range Decides for You

LoRaWAN (LPWAN): 2 to 15 km range, very low power. Built for agriculture, smart cities, and any deployment where devices sit kilometers from the nearest gateway on a single battery for years.
NB-IoT (Cellular): Nationwide range through existing cell towers, very low power. The go-to for asset tracking and smart metering where private gateway infrastructure is not feasible.
LTE-M (Cellular): Nationwide range with higher bandwidth and mobility support. Fits wearables, vehicle telematics, and devices that move between cell towers while staying connected.
Zigbee (Mesh): 10 to 100 meters in a self-healing mesh network, very low power. The standard for smart homes and building automation is where every device extends the network.
BLE (Short-range): 10 to 100 meters, very low power. Pairs naturally with smartphones, making the right choice for wearables, asset tags, and short-range sensor configuration.
Wi-Fi (high bandwidth): Around 50 meters, high power draw. Not for battery devices, but unmatched for cameras, display panels, and dashboards that need to stream data continuously.

The decision usually starts here. Range and power budget narrow your options to two or three protocols before you even think about the application layer.

Get this right at the architecture stage, and everything downstream firmware, cloud, and compliance gets significantly simpler.

For a deeper dive into all protocols with full comparison tables and industrial protocol coverage, the complete IoT protocols guide on Promeraki covers everything in detail.

What protocol stack are you running on your current IoT project, and is there one decision you would make differently if you started over?

Cloud Platforms for IoT: How to Choose Between AWS, Azure, and Google Cloud

Promeraki IoT — Mon, 25 May 2026 13:38:24 +0000

Picking a cloud platform for your IoT project feels like it should be straightforward. All three major providers offer IoT services. All three handle device connectivity, data ingestion, and analytics. On paper, they look almost identical.

In practice, they are built for very different starting points, and choosing the wrong one early on creates migration headaches that compound for years.

The right choice depends less on feature checklists and more on where your team already stands and where your product is heading.

Here is how the three actually differ when you look past the marketing pages.

AWS IoT: The Broadest Ecosystem

AWS has the widest selection of IoT-specific services. AWS IoT Core handles device connectivity over MQTT and HTTPS. IoT Greengrass pushes compute to the edge. IoT SiteWise is purpose-built for industrial data. IoT TwinMaker gives you digital twin capabilities.

Where AWS shines are flexibility. You can stitch together exactly the pipeline you need Kinesis for streaming, Lambda for serverless processing, Timestream for time-series storage, and S3 for raw archival. The building blocks are all there.

Spinning up a basic IoT thing takes one CLI command:

aws iot create-thing --thing-name "sensor-01"

The tradeoff? Complexity. AWS gives you options, not opinions. If your team does not have strong cloud architecture experience, the number of services and configuration choices can slow you down rather than speed you up.

Best fit: Teams with existing AWS infrastructure, complex multi-service architectures, or industrial IoT use cases needing SiteWise and Greengrass.

Azure IoT: The Enterprise Path

Azure IoT Hub is Microsoft's core offering device management, message routing, and tight integration with the rest of the Azure ecosystem. IoT Edge handles edge deployments. Digital twins provide modeling capabilities. And Microsoft Defender for IoT covers security monitoring across your device fleet and network layer.

Creating an IoT Hub is just as quick:

az iot hub create --name my-iot-hub --resource-group my-rg --sku S1

What makes Azure different is the enterprise integration story. If your organization already runs Microsoft 365, Active Directory, Power BI, and Dynamics, Azure IoT slots into that world without friction. Data flows straight from IoT Hub into Azure Stream Analytics, Cosmos DB, or Power BI dashboards your business team already knows how to use.

Best fit: Enterprises already invested in the Microsoft ecosystem, teams that need tight integration with business intelligence tools, and organizations where IT governance favours a single-vendor stack.

Google Cloud IoT: The Data and AI Play

Google shut down its standalone IoT Core service in August 2023, announced a year earlier in August 2022, which caught a lot of teams off guard. But that does not mean Google Cloud is out of the IoT conversation. The approach shifted.

Google now positions Pub/Sub as the ingestion layer, Cloud Functions or Cloud Run for processing, BigQuery for analytics, and Vertex AI for machine learning on device data. Partner solutions like ClearBlade fill the device management gap that IoT Core left behind.

Where Google Cloud genuinely leads data analytics and ML. If your IoT product value proposition depends on what you do with the data, BigQuery and Vertex AI are hard to beat.

Best fit: Teams building data-heavy or ML-driven IoT products, organizations already using BigQuery or TensorFlow, and projects where analytics is the core differentiator rather than device management.

Quick Comparison

So How Do You Actually Choose?

Forget feature comparison tables beyond the basics. Ask these three questions instead:

Where does your team live? If your infrastructure runs on AWS, starting an IoT project on Azure creates unnecessary friction. Platform familiarity saves months.

What matters more, device management or data intelligence? AWS and Azure lead on device lifecycle management. Google Cloud leads on what happens after the data lands.

How much do you want to assemble yourself? AWS gives you the most pieces. Azure gives you the most guided path. Google gives you the strongest analytics foundation but expects you to bring your own device layer.

There is no universal answer. There is only the answer that fits your team, your existing stack, and the product you are building.

Promeraki works with companies navigating exactly this decision from platform selection through to production-grade IoT architectures. If you are weighing your options, it is worth a conversation.

Which cloud platform are you running your IoT workloads on, and what would you change if you were starting fresh today?

Why IoT Monitoring Must Go Beyond Dashboards

Promeraki IoT — Tue, 19 May 2026 09:31:18 +0000

Most IoT teams think they are in control because they have dashboards.

Live charts.
Device status.
Alerts everywhere.

It feels like control.

But visibility is not real control.

Many OEM teams still face outages, delayed responses, and manual firefighting, even with advanced dashboards.

Because dashboards show what happened.
Modern IoT monitoring helps decide what to do next.

The shift is simple:

Seeing data - Understanding data - Acting on data

Real monitoring today focuses on:

Early risk detection
Alert prioritization
Automated response
Context-aware decisions

At scale, monitoring is not about watching devices.
It is about enabling faster, better decisions.

Read our full blog to understand how IoT monitoring is moving beyond dashboards.

Curious how modern OEM teams are approaching proactive IoT monitoring? Connect with us at Promeraki.

What Nobody Tells You About Building a Custom IoT Platform from Scratch

Promeraki IoT — Wed, 06 May 2026 12:05:52 +0000

Most connected products start on a managed IoT platform. It makes total sense you get device provisioning, a basic dashboard, and MQTT connectivity without writing much code. Ship fast, validate the idea, and learn what your customers actually need.

But somewhere between 500 devices and 5,000, things start getting uncomfortable. The data pipeline chokes during peak ingestion. The dashboard cannot show the custom views your ops team has been asking for. Protocol support is limited to what the vendor decides. And every new feature request turns into a workaround rather than a proper build.

That is usually the moment teams start wondering: should we build our own platform?

Having worked closely with IoT platform engineering at Promeraki, where we help companies architect and build custom IoT systems from the ground up, I have seen this inflection point play out across industries. Here is what the journey actually looks like.

What a Custom IoT Platform Really Involves

It is not just a dashboard wired to a message broker. A production-grade custom IoT platform has five engineering layers, and each one needs its own set of architectural decisions.

1. Device Firmware and Communication

Your devices need to communicate reliably, often over constrained, unreliable networks. That means picking the right protocol for your hardware reality. MQTT works well for lightweight pub/sub messaging. CoAP fits better when your devices speak REST over UDP. AMQP gives you message queuing guarantees when delivery order matters.

You are dealing with mutual TLS, per-device authentication, topic-level access control, and graceful reconnection handling when thousands of devices come online simultaneously after a power event.

2. Edge Processing

Not every byte of data needs to travel to the cloud. Latency-sensitive decisions, like a motor shutoff, a threshold alert, or a local control loop, should happen right at the edge. This layer filters noise, aggregates readings, and acts on data before it ever leaves the site. It is your first line of defense, and it directly cuts your cloud costs.

3. Cloud Backend and Data Pipelines

This is the core ingestion, storage, processing, and serving. Time-series databases like TimescaleDB or InfluxDB handle the volume and query patterns that sensor data produces. Message queues like Kafka decouple ingestion from processing, so traffic spikes do not bring down your pipeline.

At Promeraki, we have seen teams underestimate this layer the most. Getting data in is straightforward. Getting data reliably, at scale, with proper deduplication and late-arrival handling that is where the real engineering lives.

4. Application Layer

Dashboards, alerting engines, fleet management, OTA firmware updates, role-based access. Everything your internal team and your end customers touch daily. This is exactly where off-the-shelf platforms feel stiff because their interface was designed for a thousand different use cases, and yours was not one of them.

5. Analytics and Intelligence

Once you own the full data pipeline, you unlock what managed platforms never give you the freedom to build your own models. Historical trend analysis, anomaly detection, predictive maintenance alerts. You decide what gets analyzed, how models get trained, and where predictions show up inside the product.

When Does Custom Actually Make Sense?

Not always. And that honesty matters.

Custom IoT platform development makes sense when your device fleet is scaling past what managed pricing can sustain, when your data model does not fit the vendor's rigid schema, when you need protocol flexibility the platform refuses to support, or when your product roadmap depends on features the vendor has no reason to build.

If you are still running 50 devices and figuring out product-market fit, stay on a managed platform. Seriously. Save the custom build for when the platform's ceiling becomes your product's ceiling.

The Part That Catches Everyone Off Guard

The hardest problem is never a single layer. It is the seams between them.

Firmware topic structures need to match what your broker expects. Your ingestion pipeline must handle both real-time streams and historical batch backfills gracefully. Your dashboard needs to present edge-processed data and cloud-processed data without confusing users about what is live and what is five minutes old.

The teams that get this right treat the platform as a product in its own right with a dedicated backlog, architecture reviews, and uptime targets. The ones that struggle treat it as an internal tool someone maintains between other priorities.

Wrapping Up

A custom IoT platform spans five layers of firmware, edge, cloud, application, and analytics. Each one solves a different problem, but the real challenge lives in the integration between them.

Promeraki helped teams navigate exactly this transition from managed platforms to fully owned, custom-built IoT architectures. If this resonates, we would love to connect.

Built or migrated to an IoT platform? What is the one decision you would make differently if you started over today?

From IoT Demo to Production: What Actually Changes When You Scale

Promeraki IoT — Wed, 06 May 2026 10:47:24 +0000

You connect a few devices.
Data starts flowing.
Your dashboard looks clean.

At this stage, everything feels simple.

But real value starts when the system grows. When you move from a controlled setup to thousands of devices, continuous data, and real-world conditions, the expectations change.

This is where IoT becomes a true engineering problem.

What production IoT really looks like

In production, your system runs in an environment you do not control.

Devices connect and disconnect. Networks fluctuate. Data does not always arrive in order. Some payloads are incomplete, some delayed, some duplicated.

At the same time, the volume increases. A few devices become thousands. A few messages per second turn into a continuous stream.

A production-ready IoT platform handles all of this smoothly. It keeps data flowing, processes events in real time, and gives users reliable insights they can act on.

The shift in how you design your system

In early stages, it is common to send device data directly to APIs and store it in a database. This works well for small setups.

As scale increases, the system evolves into clear layers.

Devices communicate through protocols like MQTT. A message broker receives and manages this flow. This ensures data is handled efficiently even during traffic spikes.

A processing layer sits on top of this stream. It filters noise, validates incoming data, and applies rules. This is where real-time decisions take shape.

Storage is structured based on usage. Telemetry data goes into time-series for storage. Device and user information live in relational databases. Historical data is archived in cost-effective storage.

This separation improves performance and keeps the system stable as it grows.

Making data useful, not just available

Raw data alone does not help users.

The real value comes from how you process and present it.

Instead of showing individual readings, the system highlights trends, patterns, and meaningful signals. It answers simple but critical questions.

What changed?

Why did it change?
What should be done next?

When your platform provides this clarity, users start relying on it in daily operations.

Designing alerts that people trust

Alerting plays a key role in any IoT system.

A good alert is clear, timely, and actionable. It explains what happened and what step to take next.

A simple structure works well in practice. You classify alerts into information, warning, and critical. You add context such as duration, thresholds, and recommended actions.

This approach keeps alerts relevant and easy to understand. Over time, users begin to trust the system because it helps them respond faster and with confidence.

The role of edge computing

As systems scale, edge computing becomes an important part of the architecture.

Instead of sending everything to the cloud, some processing happens closer to the devices.

Gateways can filter data, run lightweight rules, and handle temporary network gaps. This reduces latency and improves reliability.

It also helps control cloud costs by sending only meaningful data upstream.

A practical technology setup

Many teams succeed with a simple and stable stack.

Devices communicate over MQTT. Platforms like ThingsBoard manage device data, rules, and dashboards. Tools like Node-RED help orchestrate workflows. PostgreSQL with time-series support handles storage. Docker helps deploy services consistently across environments.

The tools can vary. What matters is how well the system is structured and maintained.

Building for long-term scale

As your IoT platform grows, a few areas become important to plan early.

Device identity and secure communication ensure every device is trusted. Firmware updates allow you to improve devices without disruption. Data models evolve as new use cases emerge. Multi-tenant design helps you support multiple customers on the same platform.

When these are handled well, the system continues to scale without major redesign.

What successful IoT systems have in common

Strong IoT platforms focus on reliability and clarity.

They process data in real time. They present insights that users can act on. They combine edges and clouds in a balanced way. They grow in phases, learning and improving at each step.

Over time, they become part of everyday operations, not just a technical layer.

Closing thought

Building an IoT demo is a great start.

Building a production system is where the real impact happens.

When you design with scale, reliability, and usability in mind, your platform does more than collect data. It supports decisions, improves efficiency, and delivers long-term value.

From IoT Demo to Production: What Changes When You Scale

Promeraki IoT — Wed, 29 Apr 2026 10:54:44 +0000

TLD;R - Scaling IoT isn’t about more devices - it’s about handling unreliable networks, real-time data streams, and building layered architectures that turn data into actionable insights.

You connect a few devices.
Data starts flowing.
Your dashboard looks clean.

At this stage, everything feels simple.

But real value starts when the system grows. When you move from a controlled setup to thousands of devices, continuous data, and real-world conditions, the expectations change.

This is where IoT becomes a true engineering problem.

What production IoT really looks like

In production, your system runs in an environment you do not control.

Devices connect and disconnect. Networks fluctuate. Data does not always arrive in order. Some payloads are incomplete, some delayed, some duplicated.

At the same time, the volume increases. A few devices become thousands. A few messages per second turn into a continuous stream.

A production-ready IoT platform handles all of this smoothly. It keeps data flowing, processes events in real time, and gives users reliable insights they can act on.

The shift in how you design your system

In early stages, it is common to send device data directly to APIs and store it in a database. This works well for small setups.

As scale increases, the system evolves into clear layers.

Devices communicate through protocols like MQTT. A message broker receives and manages this flow. This ensures data is handled efficiently even during traffic spikes.

A processing layer sits on top of this stream. It filters noise, validates incoming data, and applies rules. This is where real-time decisions take shape.

This separation improves performance and keeps the system stable as it grows.

Making data useful, not just available

Raw data alone does not help users.

The real value comes from how you process and present it.

Instead of showing individual readings, the system highlights trends, patterns, and meaningful signals. It answers simple but critical questions.

What changed?

Why did it change?
What should be done next?

When your platform provides this clarity, users start relying on it in daily operations.

Designing alerts that people trust

Alerting plays a key role in any IoT system.

A good alert is clear, timely, and actionable. It explains what happened and what step to take next.

A simple structure works well in practice. You classify alerts into information, warning, and critical. You add context such as duration, thresholds, and recommended actions.

This approach keeps alerts relevant and easy to understand. Over time, users begin to trust the system because it helps them respond faster and with confidence.

The role of edge computing

As systems scale, edge computing becomes an important part of the architecture.

Instead of sending everything to the cloud, some processing happens closer to the devices.

Gateways can filter data, run lightweight rules, and handle temporary network gaps. This reduces latency and improves reliability.

It also helps control cloud costs by sending only meaningful data upstream.

A practical technology setup

Many teams succeed with a simple and stable stack.

The tools can vary. What matters is how well the system is structured and maintained.

Building for long-term scale

As your IoT platform grows, a few areas become important to plan early.

When these are handled well, the system continues to scale without major redesign.

What successful IoT systems have in common

Strong IoT platforms focus on reliability and clarity.

They process data in real time. They present insights that users can act on. They combine edges and clouds in a balanced way. They grow in phases, learning and improving at each step.

Over time, they become part of everyday operations, not just a technical layer.

Closing thought

Building an IoT demo is a great start.

Building a production system is where the real impact happens.

When you design with scale, reliability, and usability in mind, your platform does more than collect data. It supports decisions, improves efficiency, and delivers long-term value.

If you're solving similar IoT scaling problems, take a look at how we build production systems at Promeraki.

Stop guessing. Start predicting. IoT sensors are helping vineyards detect fungal outbreaks before they cost you the harvest!

Promeraki IoT — Mon, 20 Apr 2026 11:36:42 +0000

Promeraki IoT for Promeraki Developments

Apr 20

How IoT Sensors Are Predicting Powdery Mildew Before It Spreads Across Your Vineyard

#iot #vineyard #smartdevices #agritech

3 min read

How IoT Sensors Are Predicting Powdery Mildew Before It Spreads Across Your Vineyard

Promeraki IoT — Mon, 20 Apr 2026 11:33:37 +0000

Powdery mildew doesn't knock before it enters your vineyard.

One morning the vines looked fine. A week later, half the canopy is dusted white, and you're already two treatments behind. Historically, it's been managed reactively: spot it, spray it, and hope.

But that's changing.

IoT sensor networks combined with predictive ML models are shifting disease management from reaction to prediction, and the results are measurable.

What Makes Powdery Mildew So Hard to Catch

Caused by the fungus Uncinula necator, powdery mildew, doesn't need wet leaf surfaces to spread. It thrives in warm, dry-to-moderately humid conditions which makes it harder to catch using weather-only heuristics.

By the time you see the white mycelial coating on leaves or berries, the infection is already well established. The environmental thresholds that trigger it are subtle: a temperature between 20 and 27°C, moderate relative humidity, and specific leaf wetness patterns interacting differently across microzones within the same vineyard block.

Where IoT Changes the Equation

Traditional approaches rely on regional weather stations 5–20 km away. That data resolution is too coarse for microclimate variation across a single estate.

Vine-level IoT sensor networks solve this:

*Sensors per monitoring zone: *

Temperature (air + canopy)
Relative humidity
Leaf wetness
Rainfall (rain gauge)
Soil moisture

*Data flow: *
Sensor node → LoRaWAN gateway → Cloud (MQTT) → ML inference → Alert

The ML Layer

A few approaches that work well in practice:

SVM + Logistic Regression (hybrid): ANR-cleaned sensor data fed into an LR classifier achieved 96% accuracy for powdery mildew prediction in documented research.
Gradient Boosting: Effective for multi-disease classification (PM, downy mildew, black rot) when historical outbreak data is available.
Deep learning with fuzzy annotation: Used for real-time vine-level breakpoint detection that flags the exact onset window, so interventions are targeted, not calendar-based.

What Features Actually Matter

Features: Relevance
Air temperature (20–27°C): High
Relative humidity (moderate): High
Leaf wetness duration: Medium
Rainfall: Medium

Unlike downy mildew, powdery mildew does not require free water for sporulation, so leaf wetness alone won't catch it.

A Simple Risk Scoring Pipeline

def compute_mildew_risk(sensor_reading: dict) -> str:

temp = sensor_reading['temp_c'] 

rh = sensor_reading['humidity_pct'] 

lw = sensor_reading['leaf_wetness_hrs'] 

temp_risk = 1 if 20 <= temp <= 27 else 0 

humidity_risk = 1 if 40 <= rh <= 70 else 0 

wetness_risk = 1 if lw < 2 else 0  # low wetness = still favorable for PM 

risk_score = temp_risk + humidity_risk + wetness_risk 

if risk_score == 3: return "HIGH" 

elif risk_score == 2: return "MODERATE" 

else: return "LOW"

In production, a trained ML model replaces this, but the feature intuition stays the same.

Outcomes

Fewer fungicide applications targeted spraying replace calendar-based schedules
Earlier intervention models fire 3–5 days before visible symptoms appear
Better fruit quality reduced late-season pressure means cleaner harvest
Traceability logged sensor + intervention data supports certification reporting

Key Takeaways for IoT Platform Engineers

Data quality > data volume. A drifting humidity sensor produces worse outcomes than a slower but more accurate one. Edge-level calibration matters.

Latency is a real design decision. A 6-hour pipeline delay can make a disease alert useless. Evaluate end-to-end.

Domain knowledge drives feature engineering. The best models here are built by teams that understand fungal biology, not just ML frameworks.

Wrapping Up

The tech stack is mature. Sensor costs have dropped. ML tooling is accessible. What's left is platform engineering that connects the biology of a fungus to a notification on a winemaker's phone before the canopy turns white.

At Promeraki, we build IoT platform engineering solutions for OEM manufacturers and agricultural operators from sensor integration to cloud pipelines and decision-support dashboards. Working on precision viticulture or AgriTech IoT? Let's connect.🤝

Most IoT discussions focus on smart homes or industrial systems. But agriculture - especially viticulture, is where it gets interesting. Precision viticulture uses: Sensor networks, edge data, remote monitoring, and real-time analytics.

Promeraki IoT — Wed, 08 Apr 2026 12:18:07 +0000

How IoT and Data Are Powering Precision Viticulture in Modern Vineyards - DEV Community

Every vineyard looks different up closely. Soil changes from one row to the next. Some sections drain...

dev.to