Question 1

What is IoT, concretely, for a business?

Accepted Answer

The Internet of Things means capturing data from many geographically dispersed connected objects to build a collective understanding of what's happening in the field — patterns, behaviors, anomalies — rather than monitoring a single machine in isolation. This differs from Industrial IoT (IIoT), which focuses on a handful of devices inside one facility.

Question 2

What's the difference between IoT and Industrial IoT (IIoT)?

Accepted Answer

IoT deals with a massive number of geographically dispersed objects sending homogeneous data at low frequency, aimed at building collective intelligence. IIoT deals with few devices, in one facility, sending diverse data at high frequency, aimed at improving manufacturing efficiency — which is why the two need different kinds of platforms.

Question 3

What does the full lifecycle of a connected object actually cover, beyond "sending data"?

Accepted Answer

A connected object's lifecycle includes far more than data collection: firmware updates, device provisioning, identity and access management, regulatory compliance, and everything through to end-of-life. Many early IoT platforms were built as simple data pipelines — ingestion, storage, visualization — and ignored this operational reality, which is exactly why a lot of them struggled.

Question 4

Is my project actually IoT, or could a simpler solution do the job?

Accepted Answer

Not every connected-object idea needs a full IoT deployment. The LPWAN market itself is described as a "blue ocean" rather than a battlefield — different technologies serve genuinely distinct use cases rather than one universal solution fitting everything. The right starting point is defining what data you actually need, how often, and from how many dispersed points; that alone often tells you whether IoT is the right tool.

Question 5

What is LPWAN and why does it matter for IoT?

Accepted Answer

LPWAN (Low Power Wide Area Network) is a family of radio technologies built to send small amounts of data over long distances while using very little power — which is what makes battery-powered sensors viable for years in the field. Sigfox/0G, LoRaWAN and NB-IoT are the main LPWAN families, and after years of proven deployments none of them is a "wrong choice" in general — the right one depends on your use case.

Question 6

0G (Sigfox), LoRaWAN, NB-IoT: what's actually different for my project?

Accepted Answer

Sigfox/0G uses Ultra Narrow Band transmission — like a whistle cutting through noise: all the power is concentrated into a tiny bandwidth, giving long range with very simple, "plug & play" devices, at the cost of a limited daily message budget. LoRa uses spread-spectrum transmission instead — like a net rather than a beam — repeating the message across frequencies for resilience, with higher theoretical throughput but more configuration work on the device side.

Question 7

What is the 0G network and when does it make sense for a mobile or dispersed fleet?

Accepted Answer

The 0G network is the Sigfox-technology global network: a single, unified backend regardless of country, with devices that require no configuration once deployed. That "plug & play" nature and wide network footprint make it well suited to objects that move or are spread across many uncontrolled sites — exactly the case where deploying and maintaining your own infrastructure per site isn’t realistic.

Question 8

Should I deploy my own private LPWAN network, or use a public network operator?

Accepted Answer

On real numbers, a private network costs roughly €17,000–€30,000 over five years once you include gateways, installation, backhaul connectivity, management software and IT oversight — plus around 40 person-days of coordination over that period. A public operator subscription runs closer to €400–500 per year per device. As a rule of thumb, if you're not confident you'll operate more than around 500 devices on a site, a public network is very likely the more cost-effective and reliable choice; private networks make more sense for lab or test environments needing full autonomy.

Question 9

Can I trust a simple side-by-side chart comparing LPWAN technologies?

Accepted Answer

Be careful — many public LPWAN comparisons mix up things that aren’t comparable: signal strength (RSSI) depends on the antenna and transmit power used in the test, not on the technology itself, and a poorly documented range test (e.g. a technology "failing" at 9km when it is well known to reach 10–50km) usually reflects the experimental setup, not a hard technology limit. A trustworthy comparison documents its exact test conditions and avoids declaring one universal "winner", because the right technology genuinely depends on the use case.

Question 10

Is the LPWAN market already saturated, or is there still room for new projects?

Accepted Answer

After years of proven deployments, Sigfox/0G, LoRaWAN, NB-IoT and LTE-M have each demonstrated they work — the debate isn’t really "which one wins" anymore. Each technology tends to serve a distinct segment (private LoRaWAN for localized, high-density sites; Sigfox/0G for dispersed, mobile, global-scale fleets), and there is enough demand across those segments for new projects to find their place rather than compete head-on for the same use case.

Question 11

How should I choose the battery for a connected device?

Accepted Answer

Four things drive the decision: the physical form factor (button cell vs. cylindrical vs. lithium-polymer), the voltage architecture (step-up, step-down, or direct connection — step-down generally allows a wider choice of higher-capacity batteries), and critically the peak current the battery can deliver, since LPWAN radio transmissions need current peaks around 50–120 mA that not every battery chemistry handles well. Temperature matters too: cold reduces deliverable current and voltage, heat above 40°C accelerates capacity loss and raises the risk of thermal runaway (fire, explosion).

Question 12

Can I trust the battery autonomy a manufacturer announces?

Accepted Answer

Not blindly — real-world testing has shown batteries rated at 900mAh delivering only around 400mAh, and others rated 2800mAh delivering as little as 350mAh in practice. Modeling consumption from theoretical constant-current figures is also risky, because LPWAN devices draw power in short high peaks rather than a steady current. Always validate actual capacity and consumption on your specific hardware before committing to an autonomy figure.

Question 13

What are the most common mistakes when prototyping a connected object’s hardware?

Accepted Answer

The two recurring ones are trusting a battery datasheet’s capacity without testing it on the real device, and extrapolating power consumption from lab/constant-current measurements instead of the device’s actual peak-based usage pattern. Both lead to an autonomy estimate that looks good on paper and fails in the field. The recommended approach is to work with battery vendors and validate at the expected operating temperature rather than relying on intuition alone.

Question 14

Should hardware be built in-house or with a specialized integrator?

Accepted Answer

Battery and power design in particular is described as an area where it pays to work with experts rather than rely on lab intuition alone, because the gap between a datasheet and real-world behavior (capacity, peak current, temperature) is where projects most often go wrong. The same logic extends to radio integration in general: getting it right the first time avoids costly redesigns once devices are already deployed in the field.

Question 15

Do I need a full IoT platform from day one?

Accepted Answer

Not necessarily as an out-of-the-box product — a real IoT platform ("IoT ERP") can’t just be a generic, plug-and-play dashboard; it has to be adapted to your devices, processes and regulatory constraints, similar to how a traditional ERP is implemented. What you do need from the start is clarity on the operational side — how devices will be provisioned, updated and managed over their lifecycle — visualization can come after that foundation is solid.

Question 16

Why have so many IoT platforms shut down or been redesigned, and how do I pick one today?

Accepted Answer

Many first-generation IoT platforms were built by teams without real deployment experience, borrowing big-data architecture (ingestion, storage, BI dashboards) that over-provisioned for the actual data volumes of a typical fleet — expensive infrastructure solving the wrong problem, while largely ignoring the real core of an IoT system: lifecycle management, not visualization. When evaluating a platform today, check how it handles firmware updates, provisioning, identity management and compliance, not just how its dashboard looks.

Question 17

What is an "IoT ERP" and how is it different from a data-visualization dashboard?

Accepted Answer

An IoT ERP is a system built around the operational reality of a device fleet — lifecycle control and governance, identity and access management, secure data handling and compliance — rather than around charts and dashboards. Like a traditional ERP, it isn’t a generic out-of-the-box product: it needs deep customization to your specific devices, processes and regulatory context.

Question 18

What data should my connected objects actually send back?

Accepted Answer

It depends heavily on whether you’re closer to an "IoT" pattern — many dispersed objects, homogeneous low-frequency data, built for pattern and behavior analysis across the fleet — or an "IIoT" pattern — few devices in one facility, diverse high-frequency data, built to optimize a single process. Defining which pattern you’re in first avoids over-collecting data your platform then can’t make sense of.

Question 19

Is a connected object using LPWAN secure by default?

Accepted Answer

Not automatically — security depends on the technology and how it’s configured. Sigfox relies on frequency hopping and sequence numbers to protect against replay, without encrypting the payload itself by default; LoRaWAN, by contrast, implements encryption at three levels (device, application, network) — stronger protection, but only if the keys and network parameters are set up correctly, which adds integration work.

Question 20

What’s the real security difference between Sigfox/0G and LoRaWAN?

Accepted Answer

Sigfox is effectively "plug & play" — no configuration, but no built-in payload encryption, relying instead on frequency hopping and sequence numbers against replay attacks. LoRaWAN requires setting up encryption keys and network parameters, often needing extra provisioning steps on-site, but in exchange offers three-level encryption. The trade-off is simplicity versus configurable strength.

Question 21

How do you manage the lifecycle of a fleet of thousands of connected devices?

Accepted Answer

This is exactly the operational layer that basic dashboards skip: firmware updates, device provisioning, identity and access management, and regulatory compliance need to be handled continuously across the whole fleet, not just at deployment. It’s the reason IoT platforms are described as needing to evolve into "IoT ERPs" — lifecycle governance, not visualization, is the real core of an IoT system.

Question 22

What mistakes come up most often in IoT projects that struggle or fail?

Accepted Answer

A few recur across the field: choosing a platform that was really built for a different pattern — for example a relabelled IoT platform used for an IIoT project — and hitting scalability or implementation-time problems as a result; trusting a battery’s datasheet capacity instead of testing it, and ending up with far less real-world autonomy than planned; and picking a connectivity technology based on an uncontextualized comparison chart rather than the actual use case and coverage needs.

Question 23

Should I build an in-house IoT team or work with a specialist?

Accepted Answer

The recurring advice on the hardware side is telling: even experienced teams are pushed to work with experts for battery and power design rather than rely on lab intuition, because the gap between what a datasheet promises and what a device does in the field is where most projects lose time and money. The same logic applies across connectivity choice, platform architecture and lifecycle management — areas where a specialist who has already made and fixed these mistakes shortens the path considerably.

Getting into IoT: the right questions