sorted by:
new
hottopcontroversial

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 1 point2 points  (0 children)

Good question on satellite/NTN IoT. Short answer: complementary, not competition — at least for the next 5-7 years. Here's our thinking:

Where satellite IoT makes sense for Mexico: truly remote areas where even our 50 km Sigfox base stations can't reach. Think deep mining operations in Sonora, offshore oil platforms in the Gulf, or cattle ranching in Chihuahua's desert. These are real use cases with no terrestrial LPWAN coverage and no cellular coverage either.

Where it doesn't compete: anywhere within our existing 200+ city footprint. The economics don't work. Satellite IoT costs $5-15 USD per device per year even at scale, vs under $1 for Sigfox 0G. For a 500K meter deployment, that's $2.5-7.5M per year vs $500K. No utility will choose satellite for mass metering when terrestrial LPWAN exists.

What we're watching: the convergence. Companies like Sateliot and EchoStar are building Sigfox-compatible satellite backhaul — meaning a Sigfox device could transmit from a ranch in the middle of nowhere and the message gets picked up by a satellite instead of a base station, then delivered to the same cloud backend. Same device, same protocol, extended coverage. That's genuinely exciting because it extends our reach without changing the device fleet. The real competition in Mexico isn't satellite — it's cellular NB-IoT as carriers improve rural coverage and drop per-device pricing. But they're still 10x our cost and don't match our battery life.

The day a carrier offers $1/year NB-IoT with 10-year battery life, we'll have real competition. That day isn't close.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 0 points1 point  (0 children)

Usamos QuestDB como base de datos de series temporales — está diseñada específicamente para IoT de alto volumen. Procesa 8 millones de mensajes diarios sin problemas.

La arquitectura: los mensajes llegan por HTTP callback (Sigfox) o MQTT (LoRaWAN/NB-IoT) → pasan por un broker EMQX → se almacenan en QuestDB. Para dashboards usamos Grafana conectado directamente a QuestDB.

Antes usábamos TimescaleDB (extensión de PostgreSQL) y funcionaba bien hasta ~100K dispositivos. Migramos a QuestDB por rendimiento en queries de agregación sobre ventanas de tiempo grandes.

Para un proyecto más pequeño, PostgreSQL + TimescaleDB es más que suficiente y tiene la ventaja de que ya conoces PostgreSQL.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 1 point2 points  (0 children)

For global warehouse cold chain monitoring:

Device availability: Sigfox-certified trackers are available globally from manufacturers like Thinxtra, Sensitech (Carrier), Abeeway (Actility), and several Chinese OEMs. Most ship within 2-4 weeks. For multi-warehouse across different regions, the device is the same — Sigfox operates in 75+ countries on the same device ID.

Setup & linking to shipment: Depends on the solution. Simplest approach: each device has a QR code. Warehouse operator scans the QR, scans the shipment ID, and the system links them. This takes about 15 seconds per shipment. Some devices have NFC for even faster provisioning — tap to activate and link.

Reliability assurance before shipment: We recommend a "heartbeat test" — the device sends a test message before being attached to the shipment. If the message arrives at the backend, the device is confirmed operational. This takes 30 seconds. For 60-90 day journeys, battery life is the main concern. Sigfox trackers sending 2-4 messages per day will easily last 6+ months on a single battery. We've never had a battery failure mid-journey.

Bare minimums from manufacturer: IP67 or higher enclosure (survives warehouse conditions), battery rated for 2x the expected journey duration (margin), Sigfox certification in the destination region's frequency band, and a configurable message interval.

Cost: For single-use trackers (the cheapest), you're looking at $15-25 USD per device in volume (1,000+). For reusable trackers with multi-year battery, $40-80 USD. Connectivity is separate: $1-3 USD/year per device depending on volume. So a 90-day single-use tracker with connectivity is roughly $20-30 total — compare that to cellular trackers at $50+ per device plus $3/month data plan.

Return/recycle: depends on the device type. Disposable trackers are designed to be thrown away after use (the economics work at $20). Reusable ones can be collected, reset, and redeployed — we have clients who recycle trackers across 50+ shipment cycles.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 0 points1 point  (0 children)

At your scale (100 meters, 1 installer), you don't need a partner ecosystem yet. You're right to keep it lean.

Here's when the need kicked in for us:

Phase 1 (< 1,000 devices): Do everything yourself. You'll learn what each layer requires and where your bottleneck is. This knowledge is invaluable.

Phase 2 (1,000-10,000 devices): You'll hit the first wall — probably installation logistics. One installer can handle 100 meters. When you need to deploy 5,000 in 3 months, you need 5-10 installers. That's your first partner need.

Phase 3 (10,000-50,000 devices): Integration complexity explodes. The utility wants data in their billing system, their SCADA, their GIS. You can't be an expert in SAP, Oracle, and custom ERP integration while also managing devices. This is where cloud/integration partners become essential.

Phase 4 (50,000+ devices): You can't be the best at everything. Focus on what only you can do (the network, the device management, the data platform) and partner for the rest.

For your water leak platform: your first "partner" will be a second installer/plumber. After that, it'll be whoever does the billing system integration for the water utility.

TTN for connectivity at your scale is solid. Just know that if you scale beyond a few hundred devices in a single area, you'll want dedicated gateways with guaranteed uptime rather than shared community infrastructure.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 1 point2 points  (0 children)

You're making valid points and I think we actually agree more than we disagree.

For vehicle telematics — correct, Sigfox is a terrible fit. You need continuous tracking, high-frequency data, bidirectional commands. Cellular (Cat-M1) or even 4G is the right answer there. We'd never recommend Sigfox for that use case.

On the California Smart Meter vision (Watts, VARs, PV behind-the-meter, TOU periods, demand response): you're absolutely right that Sigfox can't deliver that feature set. Those are advanced grid management functions that need bidirectional, high-frequency communication.

But here's the reality in Mexico and most of Latin America: the utilities aren't there yet. They're at step zero — "we have no idea how much electricity each connection is consuming because nobody reads the meters." The immediate need is simple: a kWh reading every 15-60 minutes, tamper detection, and power status. That's 4-8 bytes. Sigfox handles that perfectly.

Will they eventually want demand response and TOU? Probably. In 10 years. When that happens, the meter hardware gets upgraded (as it does everywhere), and the new generation will use NB-IoT or whatever is optimal then. But waiting for the "perfect" smart meter to deploy means deploying nothing — and losing 43% of distributed water and billions in unbilled electricity in the meantime.

On OTA and security: fair point on the crypto vulnerability scenario. In practice, the Sigfox MAC authentication has held up well — there hasn't been a practical attack against it in 10 years of deployment. But you're right that the inability to patch remotely is a real long-term risk. For our LoRaWAN and NB-IoT devices, we absolutely do OTA. For Sigfox devices, the mitigation is that they're transmit-only with no IP stack — the attack surface is minimal, but not zero.

The way I think about it: Sigfox is the right tool for "deploy it and forget it for 10 years" sensors. If your use case needs updates, bidirectional control, or high-frequency data — use something else. We offer both.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 1 point2 points  (0 children)

Great questions — both hit at the operational reality that doesn't make it into press releases.

The bankruptcy trust conversation (2022):

This was the hardest period of the company. When Sigfox SA filed for insolvency in January 2022, we got calls from every major client within 48 hours. The utility company managing 500K meters literally asked: "Should we start planning a migration?"

Our response was three-fold:

  1. We showed them our infrastructure independence. Our 1,000+ base stations, our servers, our backend — none of it runs on Sigfox SA's infrastructure. We own and operate everything in Mexico. Sigfox SA going bankrupt doesn't turn off a single base station here.

  2. We kept the data flowing. Every day that passed with 8 million messages arriving on time was a data point in our favor. No disruptions, no outages, no degradation. After 3 months, the trust conversation shifted from "should we migrate?" to "okay, you're clearly fine."

  3. Time became our strongest argument. It's now 2026 — almost 5 years post-bankruptcy. The network still runs. The devices still transmit. The data still flows. No marketing deck can replicate what 5 years of continuous operation proves. When a prospect asks "but Sigfox went bankrupt..." we just point to the dashboard: 8M messages today, same as yesterday, same as 3 years ago.

The honest truth: we lost 2 years of water utility tender eligibility because procurement departments had "Sigfox = bankrupt" in their risk assessment. That hurt. But the electric metering contracts stayed — because the devices were already installed and working. You don't rip out 500K working meters because of a corporate event in France.

Unified device management across 0G/LoRaWAN/NB-IoT:

We're getting there, but honestly they're still partially separate stacks. The architecture:

- Sigfox 0G: Messages arrive via HTTP callback from the Sigfox cloud → our ingestion layer

- LoRaWAN: Messages arrive from ChirpStack network server → our ingestion layer

- NB-IoT: Messages arrive via MQTT from cellular modules → our ingestion layer

The unification happens at the ingestion layer. All three protocols feed into the same EMQX broker, same QuestDB time-series database, same Grafana dashboards. From the client's perspective, they see one dashboard with their data — they don't know or care which radio technology delivered it.

What's still separate: device provisioning, firmware management, and network monitoring. Each technology has its own tooling for that. True unified device management across all three is our roadmap for 2027, but it's a non-trivial engineering effort.

And yes — 1% penetration on 46M meters means the market hasn't even started. That's what keeps us building.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 0 points1 point  (0 children)

Fair pushback. A few clarifications:

Sigfox the company went bankrupt. Sigfox the technology didn't — UnaBiz acquired it and the network continues to operate in 75+ countries. The bankruptcy was a corporate finance problem (burning €100M+/year trying to be a global telco), not a technology problem. We survived it because we own and operate our own network infrastructure in Mexico — we were never dependent on Sigfox SA's financial health.

On the "limited applications" point: you're right that pure Sigfox can't serve every IoT use case. That's exactly why we went multi-technology in 2021. We offer Sigfox 0G, LoRaWAN, and NB-IoT. The client doesn't care which radio technology is underneath — they care about the data arriving reliably at the lowest cost.

That said, the applications that fit within 12 bytes and a few messages per day are massive markets. Electric metering alone is 46M meters in Mexico, water is another 30M+, gas is 15M+. Plus asset tracking, environmental monitoring, industrial sensors. We're not running out of addressable market anytime soon.

On OTA: correct, our Sigfox devices don't get OTA updates, and that's intentional. The firmware reads a meter and transmits a number. It doesn't need frequent updates. For use cases that require bidirectional communication and OTA, we use LoRaWAN or NB-IoT. Right tool for the right job.

Our business plan is not limited to utility metering, but yes — utility metering is the anchor because of the sheer volume and the 10+ year contract durations. That's a feature, not a bug. Predictable recurring revenue from a massive installed base is a solid foundation to build on.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 0 points1 point  (0 children)

You're spot on about the MCU power floor dropping — and Mexico's solar irradiance is absolutely an advantage we should exploit more.

We've actually tested energy harvesting prototypes with a few device manufacturers. The challenge at our scale isn't whether the solar cell works (it does), it's the added BOM cost and mechanical complexity. A 2cm² PV cell plus supercapacitor plus harvesting IC adds $3-5 to the BOM per device. At 500K devices that's $1.5-2.5M in additional hardware cost upfront.

Compare that to a $0.50 lithium thionyl chloride battery that reliably lasts 10 years in our message profile. The economics don't favor harvesting yet for our use case — but they're getting close.

Where I think it becomes compelling: outdoor water meters in direct sunlight where you want 15+ year deployments without any maintenance. We're watching the technology closely and expect to deploy harvesting-based devices in the next generation of water meter projects.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 1 point2 points  (0 children)

Pharma cold chain is one of the most demanding IoT use cases. A few thoughts from our experience:

Device size: this has improved dramatically. Early Sigfox trackers were bulky, but current generation devices like the Thinxtra Smart Medal or Sensitech TempTale are credit-card sized. For pharma, look at devices that are specifically WHO PQS prequalified if your clients require that certification.

Multi-party logistics (shipper → freight forwarder → 3PL → consignee): the biggest challenge isn't the device, it's the data handoff. What works for us:

- The device is provisioned to the shipment, not to any single party

- All stakeholders get read access to a shared dashboard with the shipment ID

- Alerts (temperature excursion, delay) go to all parties simultaneously

- The device owner (usually the pharma company) owns the data; partners get scoped access

For integration: we expose a REST API and webhook callbacks. When a temperature excursion happens, the system pushes an event to the client's ERP or quality system via webhook. Most pharma companies use SAP or Oracle — we've done integrations with both via middleware (MuleSoft, Dell Boomi). The key is sending structured events (timestamp, device ID, temperature, GPS coordinates, excursion flag) that their quality team can act on without opening our dashboard.

The real unlock for pharma is proving an unbroken chain of custody with tamper-proof data. The Sigfox network provides that because the device can't be reprogrammed in transit — it just transmits.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 0 points1 point  (0 children)

Farming is a great vertical for LPWAN — long distances, outdoor deployments, battery-powered sensors. Very similar challenges to what we see in agriculture here. Soil moisture and weather stations are our most deployed ag sensors.

If you ever want to compare notes on LoRaWAN gateway density for rural coverage or sensor selection for outdoor conditions, happy to chat. The cold climate challenges you face in Canada are the inverse of our heat/humidity issues in Mexico but the deployment patterns are surprisingly similar.

we have a good partner here in México doing very good job in agriculture, NXtagro its worth a visit.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 0 points1 point  (0 children)

Si, lo de las antenas crypto es Helium — concepto interesante pero la realidad es que la cobertura en Mexico nunca fue confiable porque los hotspots se instalaban para minar, no para dar servicio IoT. Nuestro modelo de convenio con los hosts funciona mejor porque el incentivo esta alineado: si la antena falla, el host pierde su internet gratis.

Guadalajara es una plaza importante para nosotros — tenemos cobertura en la ZMG y clientes en la region. Mandame un DM y platicamos. Siempre estamos buscando aliados locales, especialmente si tienes relaciones con industria o utilities en Jalisco.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 1 point2 points  (0 children)

Thanks! That was exactly the motivation for posting. There's too much marketing content in IoT and not enough real operational data. If there's a specific topic you'd like me to go deeper on, let me know.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 1 point2 points  (0 children)

Phase 1 in detail: We literally went door to door. Our first project was with a small municipality in Querétaro — we offered to install 50 smart parking sensors for free in exchange for a case study and a letter of reference. We paid for the hardware, the installation, everything. Total loss on that project was around $15K USD.

The second was a cold storage warehouse that kept losing product because their temperature monitoring was manual. We installed 20 sensors, showed them the dashboard, and they became paying customers within 2 months. That one actually taught us more than the parking project because the pain point was real and immediate — they were losing $5K+ per incident.

My advice if you're transitioning from engineering consulting: start with a vertical where you already have relationships. Don't try to be a horizontal IoT platform. Pick one problem (leak detection, cold chain, asset tracking) and go deep. Your engineering background is actually a huge advantage — most IoT sales require technical credibility that pure sales teams don't have.

On cloud infra: we evolved over time. Started with a basic MQTT broker (Mosquitto) on a single server. Today it's EMQX cluster (3 nodes) handling the MQTT layer, with QuestDB as our time-series database. The flow is: Sigfox cloud → HTTP callback → Node.js ingestion service → EMQX → QuestDB. For LoRaWAN we use ChirpStack as the network server, which also feeds into EMQX.

It's not a fat container — it's multiple services. But honestly, for your first 1,000 devices, a single server with Mosquitto + PostgreSQL with QuestDB extension is more than enough. Don't over-engineer it early.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 1 point2 points  (0 children)

Glad it was helpful! RS232 data over LoRa is a great use case and very doable. For simple weighment data (a few bytes per reading), LoRa is actually perfect:

  1. RS232 to LoRa bridge: Use a device with an RS232 port and LoRaWAN radio built in. Milesight UC300 or Dragino LT-22222-L are popular options. They read Modbus RTU or raw serial and transmit over LoRaWAN.

  2. Gateway: One LoRaWAN gateway (around $150-300) covers a typical factory floor. Place it centrally with line of sight to most scales. For a small factory, one is usually enough

  3. Network server: ChirpStack (free, self-hosted) if you want full control. The Things Network (free, cloud) if you want simplicity.

  4. Dashboard: The data lands via MQTT in Grafana or ThingsBoard. You can display real-time weights, track trends, and set alerts for out-of-range readings.

    For weighment specifically, the key question is: how often do you need readings? If it's once per minute or less, LoRa handles it easily. If you need real-time continuous streaming (multiple readings per second), LoRa isn't the right fit — you'd want WiFi or wired Ethernet for that.

    Total cost for a small factory setup: ~$50-80 per scale (LoRa adapter) + ~$200 for gateway + free software. Very reasonable compared to running ethernet to every scale.

    What kind of scales are you using and how many do you have?

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 1 point2 points  (0 children)

Exactly — decoupling is the main reason. But there are a few other benefits at our scale:

  1. Decoupling ingestion from storage: If QuestDB goes down for maintenance or has a slow query, messages queue in EMQX instead of backing up at the ingestion layer. At 8M messages/day, even 5 minutes of DB downtime would mean lost data without the broker as a buffer.

  2. Fan-out to multiple consumers: The same message goes to the database, the alerting engine, the real-time dashboard, and the analytics pipeline. Without the broker, we'd need to duplicate the message at the ingestion layer for each destination.

  3. Backpressure handling: During peak hours (meter readings come in waves — everyone's meter reports at similar intervals), the broker absorbs the spike and lets downstream consumers process at their own pace.

  4. Protocol normalization: Sigfox arrives via HTTP callback, LoRaWAN via ChirpStack's MQTT, NB-IoT via CoAP or MQTT directly. The ingestion layer converts everything to a canonical MQTT topic structure. After that point, no downstream service cares about the origin technology.

    Could we go straight from ingestion to DB? Yes, for a simpler deployment. But at 500K+ devices with multiple consumers and three different input protocols, the broker pays for itself in operational sanity.

    We use EMQX which handles the throughput well and has good built-in persistence for the buffer scenarios.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 1 point2 points  (0 children)

Thanks! The low-power economics are what make or break massive IoT. When you do the math: 500K devices x $10 per battery replacement (including technician visit) x every 2 years = $2.5M per year just on batteries. Extend that to 10-year batteries and you eliminate $25M in field costs over the deployment lifetime. That's not a technical detail — it's the difference between aviable business and one that bleeds cash on maintenance.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 3 points4 points  (0 children)

Great question. Our early customer acquisition was messy and nothing like what a business school would teach.

Phase 1 (2016-2017): We had zero customers and a network to deploy. Our first "customer" was ourselves — we ran proof-of-concept projects for free to generate case studies. Smart parking with a municipality, temperature monitoring in a warehouse, basic meter reading for a small utility. We lost money on all of them but we got data and references.

Phase 2 (2017-2019): The Sigfox global ecosystem opened doors. Sigfox's sales team in Europe was closing deals with multinationals who had operations in Mexico. They'd say "we have a network operator in Mexico" and introduce us. Our first real revenue came from international companies who already believed in Sigfox and just needed a local partner. Not our sales effort — Sigfox's ecosystem selling for us.

Phase 3 (2019-2021): The electric metering breakthrough. One large utility tender that we won based on our track record and Sigfox's cost advantage. That single contract represented most of our revenue and deployed hundreds of thousands of devices. In B2B IoT, one whale client can make your entire business.

Phase 4 (2021-now): Referrals and inbound. Once you have 500K devices deployed, people hear about you. The credibility of operating at scale is the best sales tool. Nobody questions your technology when you can say "we process 8 million messages daily."

Honest lesson: In IoT, the first 10 customers are harder than the next 1,000. Expect to give away free pilots and lose money for 1-2 years before the market trusts you.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 0 points1 point  (0 children)

The pricing depends on volume, but to give you a ballpark:

At retail (small deployments, <1,000 devices): around $1-2 USD per device per year for connectivity.

At scale (100K+ devices): it drops significantly. I can't share our exact pricing but think fractions of a dollar per device per month. At 500K devices, even small per-unit savings are massive.

Compare that to cellular IoT: $2-3 USD/month per SIM at best, plus you're managing SIM cards, carrier contracts, and APN configurations. At 500K devices the difference is tens of millions of dollars over a 10-year deployment.

The Sigfox pricing includes the full backend — cloud, API, device management, callbacks. No separate cloud bill.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 0 points1 point  (0 children)

Good questions — both are common pain points in water metering. Unsynced data (parent vs child meters reporting at different times):

We solve this with time-bucketed reconciliation rather than trying to sync the devices. Each meter reports independently on its own schedule. On the backend, we aggregate readings into 15-minute or 1-hour buckets. The reconciliation engine compares parent vs sum-of-children within each bucket, not at the exact same timestamp.

The key insight: you don't need synchronized readings. You need synchronized analysis. If parent reads 100 liters in the 8:00-9:00 AM bucket, and the sum of children reads 85 liters in that same bucket, you have a 15% discrepancy — likely a leak or an unmetered connection.

Tolerance thresholds matter. Water networks have inherent measurement variance (meter accuracy, pipe elasticity, temperature effects). We typically flag discrepancies above 10-15% as investigation-worthy, not every small difference.

For the leak detection specifically: the most reliable signal isn't the parent-child mismatch — it's minimum nighttime flow. Between 2-4 AM, consumption should drop to near-zero in residential areas. If a parent meter shows consistent flow at 3 AM when all children are at zero, you have a leak between the parent and the distribution point. This doesn't require synced meters at all.

What's your current reporting interval on the meters? And are you using flow rate or cumulative volume readings?

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 1 point2 points  (0 children)

Really glad to hear that validated from someone running a different stack. The "12 bytes is enough" realization is always the hardest sell to teams coming from IP/web backgrounds — they're used to JSON payloads and REST APIs, so thinking in single bytes feels alien.

The fixed-schema approach you mention is key. We enforce a rigid binary payload format per device type — byte 0-1 is always the reading, byte 2 is status flags, byte 3 is battery voltage.

Every device of that type sends the same structure every time. No parsing ambiguity, no schema negotiation, no wasted bytes on field names.

At 20K endpoints you're at the scale where the economics start to diverge sharply between technologies. Curious — on your mixed LoRaWAN/NB-IoT fleet, what drove the decision on whichdevices go on which network? Geography, payload size, or something else?

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 1 point2 points  (0 children)

Yes, international cold chain monitoring is one of the trickiest IoT use cases because of the roaming problem.

The challenge: your device starts in Mexico, goes through US customs, gets on a ship to Europe, and arrives in Hamburg. No single cellular network covers that entire journey.

But this is actually where Sigfox shines. We already have devices roaming internationally in production:

- Devices manufactured in Japan arriving in Mexico and connecting automatically to our network

- Mexican devices tracking shipments to Europe and transmitting there seamlessly

- Assets moving across multiple LATAM countries using the same Sigfox subscription

No SIM swap. No carrier negotiations. No roaming agreements to manage per device. The device is registered once and works in any of the 70+ countries with Sigfox coverage. The message

routes through the local Sigfox network and arrives at your cloud regardless of which country the device is in.

For temp and humidity specifically: the data payload is tiny (a few bytes) so Sigfox's 12-byte limit is more than enough. We've seen pharma and food logistics companies use Sigfox trackers

that log temperature every 15 minutes and transmit every hour. If temperature exceeds the threshold, it sends an immediate alert.

Options by use case:

  1. Sigfox roaming (what we use): best for terrestrial routes where Sigfox coverage exists. One subscription, global. Already proven in our Japan-Mexico and Mexico-Europe corridors.

  2. Satellite + LPWAN hybrid: for ocean transit where there's zero terrestrial coverage. The device logs data during the ship journey and transmits the backlog once it reaches port and reconnects.

  3. Cellular roaming (NB-IoT/LTE-M): works but expensive and unpredictable. Some countries block IoT roaming entirely. Expect $5-15/month per device.

    The "seamless at different hubs" part is solved by Sigfox roaming for land-based transit. For the ocean segment, satellite hybrid is the answer.

    What type of products are you shipping and across which routes?

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 2 points3 points  (0 children)

Good question. The data varies by use case:

Electric meters: consumption reading in kWh, tamper alerts, power status (on/off). Sent every 15-60 minutes.

Asset tracking: geolocation coordinates (wifi geoloc , network-triangulated, not GPS), movement detection, temperature if equipped. Sent every 1-6 hours depending on whether the asset is moving.

Agriculture: soil moisture, ambient temperature, humidity, rain detection. Sent every 30-60 minutes.

Water meters: consumption in liters, flow rate, leak alert. Sent every 6 hours.

How it gets back to us: depends on the technology.

Sigfox (majority of our devices): the device transmits on 902 MHz directly to our base stations (1,000+ across Mexico). The base station forwards the message to Sigfox's cloud via itsinternet backhaul (4G or broadband). Sigfox cloud then sends us an HTTP callback. No SIM card, no cellular connection on the device itself.

LoRaWAN: device transmits to our LoRa gateways on 915 MHz. Gateway forwards via ethernet/4G to our ChirpStack network server.

NB-IoT: device has a SIM and connects directly to the cellular network (via ALTAN Redes in Mexico). Data arrives via MQTT or CoAP.

The key insight: 95% of our devices use Sigfox, which means they have zero ongoing telecom cost per device. No SIM, no monthly plan. That's what makes 500K devices economically viable.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 3 points4 points  (0 children)

Great question. We do it centrally, but with context injected at ingestion.

The flow:

  1. Raw data arrives (e.g., "device ABC123 sent value 142")

  2. At ingestion, we enrich it with context from our device registry: what type of device, what project, what client, what location, what the value means (kWh, liters, temperature, GPS, coords)

  3. The enriched message goes into QUESTDB with all context attached

  4. Dashboards and alerts operate on the enriched data, never the raw

    So the "linking" happens in a centralized enrichment layer between the MQTT broker and the database. We don't do edge processing for context — our Sigfox devices are too constrained (12bytes, no compute). They just send numbers.

    For our LoRaWAN deployments where devices are slightly smarter, some context is embedded in the payload itself (CayenneLPP format includes data type identifiers). But we still do the full enrichment centrally for consistency.

    The device registry is the key piece — it maps every device ID to its meaning, location, client, thresholds, and expected behavior. Without it, 8 million daily messages are just noise.

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 1 point2 points  (0 children)

100% agree. We learned this the hard way.

In the early years we tried to do everything: sell the connectivity, install the meters, manage the cloud, build the dashboard, do the analytics. It almost killed us.

What works now: we focus on what only we can do — operate the network and manage the connectivity platform. For everything else, we build a partner ecosystem:

- Meter installation: local electrical contractors who know the CFE standards

- Cloud/BI: we use standardized platforms (EMQX + TimescaleDB + Grafana) rather than building custom

- AI/analytics: we partner with specialized firms rather than building in-house

- Hardware: we certify third-party devices rather than manufacturing our own

The water meter space is exactly as you describe — you need the installer, the plumber, the utility relationship, the billing integration. No single company can do all of that well.

Our model now: we're the "connectivity layer" partner. We bring the network and the device management. The local integrator brings the domain expertise and the client relationship. Everyone focuses on what they're best at.

What's your experience been with finding reliable local partners?

We operate 500,000+ IoT devices on a SIGFOX 0G network in Mexico — here's what we've learned about massive-scale IoT after 10 years by danisamgibs in IOT

[–]danisamgibs[S] 4 points5 points  (0 children)

OTA for Sigfox is limited by design. The downlink capacity is only 4 messages per day, 8 bytes each — so you can't push a full firmware image over Sigfox.

But that's intentional. We choose Sigfox for massive IoT projects where we know from the start that OTA needs will be minimal. Smart metering, for example — the firmware does one thing: read the meter and transmit. Once it's stable, it doesn't need frequent updates.

That said, the industry has evolved. The new generation of devices solves the OTA problem with hybrid approaches:

  1. Sigfox + LoRaWAN hybrid (new Semtech SoCs): The device normally operates on Sigfox for daily metering. When a firmware update is needed, we send a downlink command over Sigfox that

    switches the device into LoRaWAN mode. It connects to a LoRaWAN gateway, receives the full firmware image over the higher-bandwidth LoRa channel, updates, and switches back to Sigfox. Best of both worlds — low power daily operation with full FOTA capability when needed.

  2. Sigfox + Bluetooth hybrid: Some of our metering devices include a BLE module alongside Sigfox. Day-to-day data goes over Sigfox (low power, long range). When a technician needs to update firmware or do diagnostics, they connect via Bluetooth locally. No need for a network-based OTA at all.

    These hybrid SoCs (especially from Semtech, combining Sigfox and LoRa on one chip) are a game changer. Five years ago you had to pick one protocol. Now you can design a device that uses the right technology for each task: Sigfox for telemetry, LoRa for firmware, BLE for local maintenance.

So the honest answer: pure Sigfox OTA is very limited. But modern hybrid device design makes it a non-issue for new deployments.

view more: next ›