Series: LoRaWAN Technical Reading · Issue 16 (Industry Trends, No. 6) Published: 2026-09-23
When teams evaluate a platform, almost everyone asks the same set of questions: How many protocols does it support? Does it have a rules engine? How good are the dashboards? What's the cost per device?
Very few ask: Will this platform still exist in three years?
Consider an uncomfortable comparison. In 2026, the average time from industrial IoT project kickoff to first paying customer is 41 months — a figure from IoT Analytics' 2024 survey of 100 OEMs, and 80% longer than in 2020.
Over the past 24 months, six of the most-cited industrial IoT platform brands changed owners. Over the past 36 months, hyperscalers retired eight dedicated IoT services.
A 41-month build cycle against a 24-month ownership churn cycle. The company you sign with and the company you go live with are, quite plausibly, not the same company.
This is not alarmism. It is the first-order risk of platform selection in 2026. This article puts names like ThingSpeak, TTN and ThinkLink back into their proper positions, then answers a more practical question: across five classes of platform, how do you choose — and how do you guarantee you can always leave?
In 2019, the widely circulated industrial IoT platform map listed over 620 vendors. IoT Analytics' ongoing tracking finds that by Q1 2026, 188 of them had exited, retired or pivoted.
A second data set from IIM's industry report puts the global count of active IoT platform companies at roughly 620 in 2023, shrinking to 478 by 2025, with concentration (CR10) rising from 41% to 58.7% over the same period.
The two "620" figures measure different things — one is a 2019 map's inclusion count, the other a 2023 count of active companies — but they point the same way: this sector is consolidating rapidly, and the top is getting heavier.
The cause is not mysterious. Practitioners converge on the same explanation: the direct revenue from an IoT platform cannot support the market size it promises. A platform must serve hardware vendors, system integrators and end users simultaneously, and each wants something different. Without enormous order volume, the model doesn't close.
More telling still: the exits are not all small companies. Every name in the table below once appeared near the top of "best platform" lists.
| Platform | Change | Timing |
|---|---|---|
| ThingWorx + Kepware | PTC sold to private equity firm TPG (~$600M), now under Velotic | Deal closed 2026-03 |
| Cumulocity | Software AG sold to Silver Lake, later carved out to IBM | 2024-2026 |
| Particle | Acquired by Digi International | 2025-2026 |
| Losant | Acquired by SUSE | 2025-2026 |
| Bosch IoT Device Management | Product line discontinued | 2025-2026 |
| Relayr | Company dissolved | 2025-2026 |
For buyers, this has a very concrete consequence. Take ThingWorx: it publishes no pricing today, and third-party advisories estimate base licensing at $50,000 to $150,000, plus $50 to $200 per device per year, plus $1,000 to $3,000 per named user per year. Kepware drivers are licensed separately at $500 to $2,500 each.
Here is the point: Kepware raised prices 20% in June 2026 — the first visible pricing cycle under private equity ownership. A TCO model you built three years ago cannot absorb that variable.
A practical rule of thumb: you are buying the company that will own it in three years, not the brand printed on the box today.
If the default assumption has been "pick a hyperscaler and you're safe," this list deserves a careful read. These are not startup products. They belong to AWS, Azure and Google.
| Service | Status |
|---|---|
| Google Cloud IoT Core | Shut down 2023-08-16 |
| IBM Watson IoT | Exited 2023 |
| AWS IoT Things Graph | Retired |
| AWS IoT Analytics | Shut down 2025-12-15 |
| AWS IoT Events | Shut down 2026-05-20 |
| AWS IoT Fleet Hub | Retired |
| AWS IoT SiteWise Monitor | Retired |
| AWS IoT Greengrass V1 | Shut down 2026-10-07 |
| Azure Time Series Insights | Shut down 2024-07-07 |
| Azure IoT Central | Announced shutdown 2027-03-31 |
A summary from a former Microsoft IoT product lead is widely quoted: IoT services simply don't make enough money on their own.
To be precise, this is not "hyperscalers exiting IoT." Connectivity-layer services like AWS IoT Core and Azure IoT Hub continue to receive investment. What is being retired is the layer above — analytics, events, visualization, fleet management — products that require vertical workflow management. Vendors are folding those capabilities into broader data platforms (Fabric Real-Time Intelligence, lakehouse architectures). Strategically, the move is from horizontal IoT to horizontal data.
For deployers, the accounting is identical either way: the APIs you depend on, the integrations you wrote, the operational runbooks your team learned — all retire with the product.
Placed side by side, these three patterns reveal a single structural fact:
The business model of IoT platforms and the deployment cycle of IoT projects are mismatched.
These pull in opposite directions. The result is that platform vendors oscillate between "go horizontal" and "go vertical," and the oscillation produces product-line cuts, ownership changes and price adjustments.
So "will the platform disappear" is not a risk you can avoid by choosing a large vendor. It can only be avoided by architecture — specifically, by keeping your exit cost low.
Things called "IoT platforms" are not one product category. Comparing them in a single feature matrix is a common starting point for selection failure. By delivery form and dependencies, they divide into five classes.
Representatives: TTN (The Things Network) / The Things Stack Sandbox
TTN is the most influential community project in this industry, and its scale is real: over 280,000 members, 21,000 gateways, across 153 countries.
Its purpose is equally clear — to let people connect a LoRaWAN device for the first time at the lowest possible threshold. It is free, open, well-documented, and backed by a rich device repository.
But several boundaries must be understood:
Fits: learning, proof of concept, non-critical long-interval data collection. Does not fit: any commercial deployment requiring committed availability.
One frequently conflated point: TTN community network and The Things Stack commercial editions are different things. TTS Cloud offers Discovery (free, with SLA), Standard (1,000 devices included) and Plus (adds NOC and invoicing); the enterprise self-hosted edition typically targets fleets above 50,000 devices. The software itself is Apache-2.0 licensed, which means self-hosting is genuinely possible — but that also returns you to the self-operated category.
Representatives: ChirpStack, ThingsBoard Community Edition, Eclipse Ditto/Hono
This class has grown fastest over the past five years. The pitch is one sentence: the software is free, the data is yours, and there is no per-device billing.
Take ChirpStack. Several hard facts:
ThingsBoard Community Edition follows a similar path under Apache-2.0, with more complete rule engine and dashboard capabilities; its Professional self-managed tier runs $10 to $499 per month per node, and cloud tiers span $749 to $3,999 per month.
Where does the real cost sit for this class?
The software is zero; the cost moves elsewhere:
| Cost item | Order of magnitude |
|---|---|
| Server / hosting | From ~€5/month, or marginal on existing infrastructure |
| Gateway hardware | One-time; €150-400 indoor, €500-900 outdoor |
| Sensors | One-time; typically €20-150 each |
| Operations & maintenance | Internal time, or MSP retainer |
| Support / SLA | Optional, via integrator; no vendor subscription |
Commercial support for ChirpStack is available from Orne Brocaar, its author; community support runs through the forum and GitHub issues. There is no default SLA. That is a structural characteristic of this class, not a defect.
Fits: teams with in-house engineering or a stable integration partner; data sovereignty or compliance requirements; device counts that will grow until per-device billing becomes expensive. Does not fit: teams with no one to own operations; mission-critical workloads requiring a committed SLA.
Representatives: AWS IoT Core, Azure IoT Hub
The strength here is ecosystem and scale. If your systems already run on AWS or Azure, native integration with Lambda, Functions and data lakes saves substantial integration effort. AWS's managed connectivity can support billions of devices and trillions of messages.
The pricing structure deserves close reading. The following reflects published rates as of 2026:
| Billing item | AWS IoT Core | Azure IoT Hub |
|---|---|---|
| Connectivity | $0.08 per million connection minutes | Included in unit price |
| Messaging | $1.00 per million messages (metered in 5 KB blocks) | Per unit; S1 $25/unit/month (400,000 messages/day) |
| Shadow / Registry | $1.25 per million operations | Included in unit price |
| Rules engine | $0.15 per million triggers + $0.15 per million actions | Routing to Event Hubs / Storage at no extra charge |
| Free tier | 500,000 messages/month for the first 12 months | F1: 8,000 messages/day, 500 devices |
| Higher tiers | Tiered down to about $0.70 per million | S2 $250 (6M/day), S3 $2,500 (300M/day) |
For 10,000 devices reporting once per minute (roughly 432 million messages per month), an independent model puts the AWS bill at about $596 per month — $432 messaging, $34.56 connectivity, $129.60 rules engine. The same scenario on Azure lands around $750 per month.
Here is a detail that is especially punishing for LoRaWAN: block metering.
AWS meters in 5 KB blocks; Azure in 4 KB blocks. Which means: a 100-byte LoRaWAN uplink is billed as a full 4 KB unit on Azure.
Effective payload utilization is 100/4096, about 2.4%. You pay for 97.6% empty bytes.
This is not a vendor flaw — block metering is a reasonable simplification for high-throughput workloads. But for LoRaWAN's profile of small payloads, low frequency and many endpoints, it is the worst possible combination. That is the core problem Section 4 expands on.
Representatives: ThingSpeak, Ubidots, Blynk, TagoIO, Losant, Thinger.io
The value here is speed to first data. Register, grab a key, publish, see a chart — often in an afternoon. Pricing is also the most transparent:
| Platform | Free tier | Paid entry point |
|---|---|---|
| ThingSpeak | Non-commercial; ~3M messages/year (~8,200/day), 4 channels, 15-second minimum interval | Annual units; 1 unit = 33M messages/year + 250 channels (Standard) |
| Blynk 2.0 | 2 devices | Maker $4.99/month (5 devices), Pro $14.99/month (unlimited) |
| TagoIO | 5 devices, 5 dashboards | Starter $49/month, Scale $199/month |
| Ubidots | — | Education $599/year, 300 devices |
| Losant | — | $500/month, 1,000 devices |
| Thinger.io | — | $49/month 100 devices, $299 1,000 devices, $999 10,000 devices |
ThingSpeak deserves separate treatment, because it is the most misunderstood.
It is a hosted service operated by MathWorks, the maker of MATLAB, dating back to ioBridge origins in 2010. Its moat is precise: MATLAB analytics embedded in the service. You can run MATLAB code on incoming data — signal processing, curve fitting, statistics, machine learning — without a local license.
That capability is close to irreplaceable in research, teaching and engineering prototype contexts. But it is not a general-purpose IoT platform, and MathWorks does not position it as one.
Its capability boundaries make this clear:
So the correct use of ThingSpeak is: prototype where analysis is easiest, build production where production belongs. Those are usually not the same platform.
Representatives: ThinkLink, Actility ThingPark, LORIOT
This class solves an architectural problem: a standard LoRaWAN deployment requires more than one piece of software.
The conventional approach is one network server, one application platform, one visualization tool, plus an integration layer to connect them. Four systems, four configurations, four sets of patches.
The integrated approach compresses this into one thing.
Take ThinkLink. It is an open LoRaWAN application platform developed by ManThink, with a natively integrated LoRaWAN network server. That means OTAA/ABP activation, the full gateway and device lifecycle, and live NS/AS traffic debugging all live in one system.
It offers three deployment forms, and the design is worth noting:
| Form | Where it runs | Device capacity | Positioning |
|---|---|---|---|
| Cloud | Official SaaS at thinklink.manthink.cn | 1,000 devices (permanently free), ~100k records/day | Pilots, small to mid projects, zero ops |
| TKE (ThinkLink-Edge) | Local server or industrial PC | 1,000 devices, unlimited data processing and storage | Data sovereignty; reference config 8-core / 8 GB / 64 GB eMMC |
| TKG (ThinkLink-in-Gateway) | Embedded in the gateway (GDO51 / GDI51) | 100 devices, ~10k records/day | One gateway is a complete LoRaWAN system, no server needed |
The key point: thing models, RPCs and trigger rules are written once, then moved between the three forms. Cloud pilot, self-hosted production, in-gateway deployment — same business logic, no rewrite.
The remaining capabilities follow the class standard:
There is one more capability especially relevant to retrofit scenarios: EdgeBus. Wired meter protocols — Modbus, DL/T645, CJ/T188, M-Bus — become wireless through EdgeBus, with one collector serving an entire RS-485 bus. The accompanying KC series collectors (KC11 has over 100,000 units deployed) exist for exactly this.
This class is not without cost: your business logic binds more deeply to the platform. So the evaluation criterion inverts — the question is not how many features it has, but how standard its data egress is. ThinkLink uses MQTT forwarders and can coexist with ChirpStack (bidirectional uplink and downlink routing, reusing existing decoder scripts). That matters more than any feature list.
| Dimension | Community network | Open source self-hosted | Hyperscaler managed | General SaaS | Integrated NS + platform |
|---|---|---|---|---|---|
| Examples | TTN / TTS Sandbox | ChirpStack / ThingsBoard CE | AWS IoT Core / Azure IoT Hub | ThingSpeak / Ubidots / Blynk | ThinkLink / ThingPark / LORIOT |
| Software cost | Free | Free (MIT / Apache-2.0) | Usage-based | Subscription | Free tier + paid tiers |
| Deployment | Third-party cloud | Your own machines | Vendor cloud | Vendor cloud | Cloud / on-prem / gateway |
| Data sovereignty | Low | Complete | Low (extraterritorial reach) | Low | Complete (self-hosted form) |
| Operational burden | Vendor | Yours | Vendor | Vendor | Vendor or yours (optional) |
| SLA | None | Purchased separately | Yes | Yes | Tier-dependent |
| Exit cost | Low (exportable) | Lowest | High | Medium | Medium (standard MQTT) |
| Time to start | Fast | Moderate (~half a day with Docker) | Moderate | Fastest | Fast |
| Suitable scale | Prototype | Mid to large, with a team | Already on that cloud | Small to mid | SMB to enterprise |
This section addresses the direct question in the title. But first, a caveat: strictly speaking, these three are not competitors. They solve problems at different layers.
The layering is: TTN and ThinkLink both occupy the network layer (the former as a community public network, the latter with a built-in NS), while ThingSpeak sits above, focused on data and analysis.
| Dimension | ThingSpeak | TTN | ThinkLink |
|---|---|---|---|
| Positioning | Data aggregation + MATLAB analytics | Community LoRaWAN public network | Native NS + application platform |
| Billing | Free tier non-commercial (~3M msgs/year); paid in annual units (33M msgs/year) | Community free (fair-use ~30 s/day/device) | Cloud free forever up to 1,000 devices (~100k records/day); self-hosted unlimited, no license fee |
| Data location | MathWorks cloud only | Third-party cloud | Cloud / on-prem / in-gateway (fully self-held) |
| Device management | None (channel-based, 8 fields/channel) | Yes (full NS layer) | Yes (thing models + RPC + asset/sub-device) |
| Commercial limits | Free tier non-commercial; Standard license required otherwise | No SLA; not recommended for critical commercial deployment | Free tier is commercial-ready; self-hosted unrestricted |
| Scale ceiling | Free 4 channels; Standard 250 channels | Depends on community gateway coverage | Cloud 1,000 devices; TKE 1,000 devices with unlimited storage |
| Exit cost | Medium (CSV export, limited standard API ecosystem) | Low (standard LoRaWAN + MQTT) | Low-medium (standard MQTT forwarding, ChirpStack coexistence) |
First, ThingSpeak's free tier looks large in messages and is actually small in devices.
The free tier offers 3 million messages per year and 4 channels. But ThingSpeak's model is "one connected device typically requires one channel." In other words, the free tier effectively connects 4 devices.
Switch to a sensor reporting 96 times a day (every 15 minutes) and four devices consume about 140,000 messages a year — nowhere near the 3 million ceiling. The real constraint is channels, not messages. This is not obvious on the product page, but the licensing FAQ states it plainly.
Second, TTN and ChirpStack are not a "free versus paid" pair.
Many assume TTN is the free option and ChirpStack is the build-it-yourself option. In fact The Things Stack software is also Apache-2.0 licensed, and both can be self-hosted. The real difference is:
This is a trade between operational responsibility and degree of control, not a price trade.
Third, the biggest value of an integrated platform is not saving on software — it is saving the integration layer.
One number comes up repeatedly in the platform consolidation story: in a 2026 survey of 272 industrial professionals, 48% named legacy integration and data silos as the top barrier to AI adoption. Only 22% had MQTT widely deployed, and only 13% had a unified namespace running.
The conclusion is clear: the integration layer is where IoT projects die.
So compressing NS, application platform, visualization and integration into one install is not about saving a few software subscriptions. It is about eliminating three or four interfaces that need long-term maintenance. Fewer interfaces means fewer failure points — and a smaller migration surface when the time comes to switch.
For comparability, use one concrete scenario: 10,000 devices, each reporting every 15 minutes, 50-byte payloads, over five years.
Monthly message volume = 10,000 × (30×24/15) × 30 ≈ 28.8 million per month.
| Approach | Five-year cost structure | Notes |
|---|---|---|
| General SaaS (Losant tier) | $500/month for 1,000 devices → ~$2,000/month for 10,000 | ~$120,000 over five years |
| AWS IoT Core | Messaging ~$28.8/month + connectivity ~$34.6/month + rules engine | ~$4,000-6,000 over five years (excl. storage and analytics) |
| Azure IoT Hub | 28.8M/month ≈ 960k/day → 3 S1 units ($75/month) | ~$4,500 over five years |
| ChirpStack self-hosted | Cloud VM ~$10/month + operational time | ~$600 plus labor over five years |
| ThinkLink Cloud | Free tier 1,000 devices → self-host for 10,000 | No license fee; Docker Compose deployment |
| ThinkLink TKE | One-time hardware (8-core/8 GB/64 GB industrial PC) + no license fee | Five-year cost is hardware and operations only |
The easiest way to misread this table: usage-based cloud billing does not look expensive at this scale.
True. At 28.8 million messages a month, the AWS and Azure bills are only tens of dollars. What pushes costs out of control is not this scenario.
The problem with usage-based billing is not the absolute number. It is the shape of the curve.
Variable one: reporting frequency. Move from every 15 minutes to every minute and volume grows 15×. That $28.8 becomes $432.
Variable two: block metering. As noted, Azure meters in 4 KB blocks and AWS in 5 KB blocks. A 50-byte payload yields about 1.2% effective utilization. Switching to 500-byte aggregated payloads leaves the bill unchanged while carrying 10× the data — this is the only real hedge against block metering: make payloads larger, not more frequent.
Variable three: downlink. LoRaWAN downlink capacity is far smaller than uplink, but cloud billing does not distinguish direction. Control applications (remote configuration, threshold updates) push message counts up materially.
Variable four: device count. Going from 10,000 to 100,000 devices scales the cloud bill linearly, while a self-hosted server cost barely moves. Multiple independent estimates converge: beyond a few thousand devices, the self-hosted cost advantage becomes visible.
Layer on one more figure: a January 2026 Gartner analysis found that 68% of enterprises with more than 250,000 endpoints named unpredictable monthly billing as the top challenge of per-message pricing.
So the substance of the issue is this: the real cost of usage-based billing is not money — it is uncertainty. A firmware bug triggering a retry loop can blow through the bill in hours, which is why AWS's own documentation treats Budgets and Device Defender throttling rules as mandatory rather than optional.
First, operations labor.
Self-hosting is not free; it converts license fees into hours. ChirpStack deployment itself is not hard (Docker Compose, up and running in half an hour), but long-term ownership requires someone responsible for updates, monitoring, backups, security and observability. That role is either internal headcount or an MSP retainer. If that person does not exist on your team, the true cost of self-hosting is far above the server line item.
Second, compliance and certification.
Admission requirements differ by market, and this cost is often omitted from early planning.
Third — and most expensive — migration cost.
Data from the Eclipse Foundation IoT Working Group and PW Consulting: when switching between major commercial platforms, migration cost can consume 35% to 60% of the migration budget.
That number explains why lock-in is a real cost rather than a psychological one. It also explains why the next section matters so much in 2026.
Avoiding vendor lock-in used to be an engineering taste, a mark of prudence. As of 2026, it has become a legal requirement in two major markets simultaneously.
The EU Data Act (Regulation (EU) 2023/2854) has applied since 12 September 2025. But the real watershed is this date.
From 12 September 2026, the "data access by design" obligation in Article 3(1) applies.
It requires that connected products placed on the EU market and their related services make product data, related service data and associated metadata accessible to users by default — easily, securely, free of charge, in a comprehensive, structured, commonly used and machine-readable format, and where relevant and technically feasible, directly accessible.
Several key points:
Penalties are significant. Germany has proposed fines up to 4% of global annual turnover or €5 million; France, through its SREN law, set ceilings at 3%, rising to 5% for repeated breaches.
China's policy signals point the same direction, expressed differently.
On 31 March 2026, nine Chinese government departments including the Ministry of Industry and Information Technology jointly issued the "Action Plan for Promoting Innovative Development of the IoT Industry (2026-2028)." Its targets: by 2028, formulate or revise more than 50 advanced and applicable standards; cultivate 10 application domains with billion-level connections and 15 with ten-million-level connections; push IoT terminal connections toward the hundred-billion scale; and exceed RMB 3.5 trillion in core IoT industry output.
One passage deserves to be read word for word:
Promote the formulation of unified IoT data standards, and facilitate cross-brand, cross-terminal and cross-platform interoperability of product data.
The plan also acknowledges three current problems: some key core technologies are constrained by others, different terminal devices cannot interoperate, and network and data security risks are intensifying.
In other words, "cross-platform interoperability" is explicitly framed as a problem to be solved, not an option.
The supporting standards framework is being built in parallel:
| Standard | Content | Status |
|---|---|---|
| GB/T 47949-2026, Asset Management: Data Asset Classification and Codes | Classifies data assets into structured / semi-structured / unstructured, with 15 subcategories | Published 2026 |
| GB/T 47950-2026, Asset Management: Data Asset Registration Guide | Three registration processes: initial, change and deregistration | Published 2026 |
| GB/T 47969-2026, Industrial Internet Data Element Registration Requirements | First national standard for industrial internet data element registration | Effective 2027-02-01 |
The accompanying industrial data asset registration platform has launched a national node plus city nodes in Suzhou, Beijing and Shenyang, issuing 2,045 registration certificates to date.
The implication of this thread: data must be exportable, and it must be accountable. Both require that data not be locked inside a platform that cannot export it.
Taken together, the requirements of both markets mark a fundamental shift in selection criteria.
The old question: what can this platform do for me? The new question: what can I take away from this platform, in what format, in how long, at what cost?
This resolves into four hard indicators:
Distilling the analysis into an executable process. Six questions, answered in order.
Question 1: Can the data leave your premises?
No (or unwilling) → Rule out community networks and pure hosted SaaS immediately. Choose from open-source self-hosted or integrated platforms with a self-hosted option.
Yes → continue.
Question 2: Does anyone on the team want to own operations long-term?
No → Choose managed (hyperscaler or SaaS), or start on an integrated platform's free cloud tier.
Yes, but part-time → Prefer the integrated platform's managed tier to minimize the operational surface; consider self-hosting once scale arrives.
Yes, dedicated team → Open-source self-hosted or integrated self-hosted; best cost outcome.
Question 3: Is the device protocol profile homogeneous?
LoRaWAN only → Any class works.
LoRaWAN + wired meters (Modbus / DL/T645 / CJ/T188 / M-Bus) → This single question eliminates most platforms. Ask specifically: does the platform natively support these protocols, or does it need an extra gateway or DTU for conversion? In retrofit scenarios this is usually decisive.
Question 4: What shape is the five-year bill curve?
Device count and reporting frequency fixed and modest → Usage-based billing is acceptable; choose managed for convenience.
Device count will grow, reporting frequency may change → Model the 3× and 10× scenarios. If the curve is steep, self-hosting is the more stable choice.
Question 5: How deeply does your business logic depend on the platform?
Just storing data and viewing charts → Any platform is replaceable; choose the easiest.
Complex rules, automation, remote control → Look at two things: whether logic can be written in a general-purpose language (JavaScript / Python rather than a proprietary DSL), and whether data egress is standard. These two determine your future migration surface.
Question 6: Are there regulatory or contractual constraints on data location?
Yes (EU EPBD / GDPR / Chinese data classification requirements, or explicit customer contract terms) → Data sovereignty is a hard constraint; choose self-hosted.
No → You have more freedom to trade off.
The previous six sections laid out a general framework. This section explains what ManThink chose to do with ThinkLink — and what it chose not to do.
One thing done: merging NS and application platform into a single install.
This is a direct response to the judgment that the integration layer is where projects die. In conventional architecture, NS, application platform, visualization and integration are four separate systems; ThinkLink builds them into one. Three fewer interfaces means three fewer long-term maintenance points and a smaller migration surface down the road.
One thing done: three deployment forms sharing one set of business logic.
Cloud (free up to 1,000 devices), TKE (local server) and TKG (in-gateway) — thing models, RPCs and trigger rules are written once. This targets a specific pain point: pilot and production environments differ.
Many projects die at the "PoC to production" step, partly because the hosted service used for the PoC and the private environment required for production are two different systems with logic that must be rewritten. If the logic itself can move, that step costs far less.
One thing done: making the data egress standard.
Forwarding to ThingsBoard, Home Assistant and any third-party MQTT broker is supported; ThinkLink can coexist with ChirpStack v4 via MQTT forwarders, routing uplink and downlink bidirectionally while reusing existing ChirpStack decoder scripts.
That last point deserves emphasis. A platform that lets you coexist with its own substitute is a practical signal about whether it depends on lock-in for revenue.
One thing done: bringing the installed wired base online.
EdgeBus supports Modbus, DL/T645, CJ/T188 and M-Bus, with KC series collectors (over 100,000 KC11 units deployed) serving an entire RS-485 bus from one device. In Question 3 of the decision tree, this is the capability that separates platforms most sharply.
One thing not done: making every capability free.
The free tier has explicit boundaries (1,000 devices, ~100k records/day). That is the honest approach — an open-source project with no business model is the one whose survival you should actually worry about.
One thing also not done: promising to solve everything.
It is not a general-purpose IoT platform (that is ThingsBoard's and the hyperscalers' lane), nor an analytics platform (that is ThingSpeak's lane). It is a complete LoRaWAN system from device to application. Whether it fits should be judged by whether that boundary covers your needs — not by whether its feature list is longer than someone else's.
Misconception 1: Open source means free.
Open source removes the license fee, not the total cost of ownership. Servers, operations labor, backups, security, observability — all of it counts. ChirpStack's software costs zero, but a network with a few thousand devices needs someone accountable for it long-term. If that person does not exist, "free" is the most expensive option.
Misconception 2: A large vendor means stability.
Between 2023 and 2026, Google, IBM, AWS and Azure retired at least ten IoT-related services in total. Brand size is not a commitment about a specific service. Look at the service's roadmap and maintenance status, not the company's market cap.
Misconception 3: More features means a better platform.
Feature matrices are the easiest information to fake. What actually matters is three things: whether data egress is standard, whether business logic can be written in a general-purpose language, and whether export costs are transparent. These determine your future freedom; feature count only determines your present comfort.
Misconception 4: SaaS is always cheaper than self-hosting.
At small scale, low frequency and short duration, usually true. But the usage-based curve is exponential in shape: device count, reporting frequency, downlink volume and block metering — amplifying any one of the four materially changes the bill. Compare not today's bill but the bill three years out.
Misconception 5: Choosing LoRaWAN means you cannot be locked in.
LoRaWAN is an open standard, and that genuinely protects you at the device layer — changing platforms will not scrap your terminals. But lock-in happens at the application layer: your thing models, your decoder scripts, your rule logic, your historical data format. An open protocol does not equal free data.
Four sentences.
First, platform-layer risk has shifted from "does it have enough features" to "will it survive." A 41-month average deployment cycle against six top brands changing owners in 24 months and ten hyperscaler services retired in 36 months — the first question when choosing a platform should be "will it still be here in three years?"
Second, ThingSpeak, TTN and ThinkLink are not equivalent products and should not be compared in one feature matrix. ThingSpeak is a data aggregation and MATLAB analytics service (free tier non-commercial; 4 channels is the real constraint). TTN is a community public network (zero ops, but no SLA and a fair-use quota). ThinkLink is an integrated NS-plus-application platform (three deployment forms; Cloud free to 1,000 devices; self-hosted with no license fee). Separate the layers first, then compare parameters.
Third, the key TCO question is not the absolute number but the shape of the curve. At 28.8 million messages a month, the cloud bill may be only tens of dollars; but block metering drops effective utilization of a 50-byte payload to about 1.2%, and a 15× increase in reporting frequency is a 15× increase in the bill. A few thousand devices is the inflection point worth re-running the numbers at.
Fourth, from 2026 onward, "exitability" has moved from engineering taste to legal requirement. The EU Data Act's access-by-design obligation took effect on 2026-09-12, proprietary interfaces are no longer permitted, and cloud switching charges go to zero on 2027-01-12. China's nine-department action plan explicitly requires "cross-brand, cross-terminal and cross-platform interoperability," with supporting data asset standards following.
Both point to the same conclusion: future platform competition is no longer about who can keep you — it is about who can still be chosen when you are free to leave at any time.
For buyers, the selection criteria deserve the same inversion: from "what can this platform do for me" to "what can I take away from it, in what format, in how long, at what cost."
| Term | Description |
|---|---|
| NS (Network Server) | The LoRaWAN network server. Handles device activation, de-duplication, MAC command management, downlink scheduling, frame counter control and roaming — the core of a LoRaWAN network |
| AS (Application Server) | Handles application-layer processing of uplinks and downlinks, payload decoding and data forwarding |
| AEP | Application Enablement Platform. Provides device management, rules engine and visualization at the application layer |
| Open Core | An open-source business model: core functionality open, advanced features or managed services charged |
| Fair-use | A fair-use policy. Community networks substitute a traffic quota for hard limits |
| Block metering | Cloud vendors meter messages in fixed-size blocks (AWS 5 KB / Azure 4 KB); a partial block is billed as a full block |
| Vendor lock-in | Migration cost to another supplier is high enough to make replacement effectively impossible |
| Data egress | The process and cost of exporting data out of a cloud platform |
| EdgeBus | ManThink's edge protocol adaptation layer, bringing wired protocols such as Modbus / DL/T645 / CJ/T188 / M-Bus onto LoRaWAN |
| FUOTA | Firmware Update Over The Air for LoRaWAN |
| TKE | ThinkLink-Edge, ThinkLink's local server deployment form |
| TKG | ThinkLink-in-Gateway, ThinkLink's in-gateway deployment form |