It includes all functionalities available at the TagoIO platform plus complete control of your resources. It is ready to scale up based on your instance performance at the best cost.
We removed the necessary limitations imposed in the multi-tenant TagoIO platform so you can set your request per minute (RPM), mutable bucket sizes, number of tags, and more.
Enjoy all the powerful features of TagoIO with dedicated resources tailored to your business. Create custom dashboards, perform real-time data visualization, and run custom analysis in a fully isolated environment.
With TagoRun fully integrated, you can also deploy custom white-label applications to your customers, manage permissions, and build tailored user experiences.
Hosted on AWS, this solution provides scalability, security, and reliability, giving you full control and customization without shared infrastructure.
Dedicated Resources Only for You Complete control and isolation for your platform. Your own URL for APIs, Admin, and custom domains. TagoDeploy All the tools to give you full control over a customized deployment. Why choose TagoDeploy Reliable performance and global scalability for your needs. --- ## TagoTiP | Lightweight IoT Telemetry Protocol | TagoIO https://tago.io/tip TagoTiP is a lightweight, human-readable IoT telemetry protocol for UDP, TCP, HTTP, and MQTT. 4.3x smaller than HTTP/JSON. Free and open-source. One Cloud. Every Transport for IoT. TagoTiP is a lightweight, human-readable IoT telemetry protocol and end-point for UDP, TCP, HTTP, and MQTT. Built for constrained devices and real networks Everything you need to send telemetry data reliably. Less overhead and more clarity. Less bytes. More signal. See how TagoTiP compares with a standard HTTP/JSON request for IoT sensor readings. --- ## IoT Analytics: Forecasts, Anomaly Detection, and Predictions | TagoIO https://tago.io/analytics TagoIO IoT analytics turns sensor data into forecasts, anomaly detection, and time-to-threshold predictions. No ML code required. Outputs land as regular variables in your dashboards, alerts, and white-label apps. The IoT analytics layer that predicts. Dashboards tell you what already happened. TagoIO analytics reads the telemetry you already collect and tells you what happens next: forecasts with confidence bands, anomaly scores against learned normal behavior, and countdowns to the moment a variable crosses a limit. No ML code and no data science team required. What can IoT analytics do with your sensor data? Three capabilities, each trained on the history already in your device buckets, each writing results back as regular variables. Setup is a guided wizard: pick devices, pick signals, choose a behavior, install. See it work. Built on published science, engineered for telemetry. --- ## Pricing and Plans for IoT platform | TagoIO https://tago.io/pricing Start for free with 5 devices and 5 dashboards. Scale with Starter, Scale, or Deploy plans. Transparent pricing for your IoT applications. --- ## Pricing and Plans for IoT platform for Europe | TagoIO https://tago.io/pricing-eu Start for free with 5 devices and 5 dashboards. Scale with Starter, Scale, or Deploy plans. European servers with transparent pricing. --- ## TagoIO Cost Calculator https://tago.io/cost-calculator Estimate monthly TagoIO platform cost for the US region based on devices and data volume. --- ## TagoDeploy Cost Calculator https://tago.io/cost-calculator-deploy Estimate TagoDeploy dedicated instance pricing. --- ## About TagoIO | Full-Stack IoT Cloud Platform Company https://tago.io/about TagoIO is a full-stack IoT cloud platform company founded in 2014 in Raleigh, NC. Customers in more than 130 countries. ISO 27001 certified. Rated 4.9 on G2. TagoIO is a full-stack IoT cloud platform company founded in 2014 and headquartered in Raleigh, North Carolina. We help businesses in more than 130 countries turn sensor data into working IoT solutions, without the cost and complexity of building cloud infrastructure from scratch. We built the IoT platform we wished we had TagoIO started in 2014 with one goal: make IoT solutions that anyone can build and trust. Founder and CEO Fabio Rosa spent more than two decades across firmware, hardware, connectivity, and product before starting the company, and he kept hitting the same wall. The hard part of IoT was never the sensor. It was everything after: the cloud, the data, the dashboards, the users. So we built one place to connect any device, store and process the data, design the dashboards, manage the users, and ship to production. Simple to start, affordable as you grow, with full control when you need it. Today TagoIO runs production IoT for companies in more than 130 countries, from single-site pilots to fleets of thousands of devices. We have been cash-flow positive and growing for years, with enterprise customers on multi-year contracts. We answer to our customers, not to a funding clock. Bosch, Semtech, TEKTELIC, and Novus build on TagoIO, alongside system integrators, OEMs, and product teams across agriculture, buildings, energy, industrial, and logistics. --- ## TagoIO Partners https://tago.io/partners Browse the TagoIO partner network: system integrators, hardware providers, and consultants. --- ## TagoIO Devices Catalog https://tago.io/devices IoT devices and connectors integrated with TagoIO across LoRaWAN, cellular, and other networks. --- ## TagoIO FAQ https://tago.io/faq Common questions about the TagoIO platform, pricing, security, and support. --- ## Contact TagoIO https://tago.io/contact-us Get in touch with the TagoIO team for product questions or custom IoT solutions. --- ## TagoIO Trust and Security https://tago.io/trust Security certifications including ISO27001, GDPR compliance, and data protection commitments. --- ## IoT Platform for Smart Agriculture https://tago.io/agriculture Silo and feed forecasting, smart irrigation, livestock tracking, and agricultural research with TagoIO. --- ## IoT for Smart Buildings https://tago.io/buildings Smart building management and facility monitoring with TagoIO. --- ## IoT for Energy https://tago.io/energy Solar monitoring, grid management, and energy efficiency with TagoIO. --- ## IoT for Industrial https://tago.io/industrial Manufacturing automation and predictive maintenance with TagoIO. --- ## IoT for Logistics https://tago.io/logistics Fleet tracking and cold chain monitoring with TagoIO. --- ## TagoIO vs. Alternatives | Compare IoT Platforms https://tago.io/compare Comparing IoT platforms? See how TagoIO relates to AWS IoT, Azure IoT, ThingsBoard, Ubidots, Datacake, Blynk, and other alternatives, so you can pick the right fit for your project. TagoIO vs. alternatives Choosing an IoT platform is a long-term decision. These comparisons walk through how TagoIO and other platforms approach device connectivity, dashboards, custom logic, end-user applications, and pricing, so you can pick the right fit for your project. Why teams choose TagoIO --- ## TagoIO vs. Akenza https://tago.io/compare/akenza Compare TagoIO and Akenza on connectivity management, data flows, dashboards, white-labeling, deployment options, and pricing models. Akenza and TagoIO are both low-code IoT platforms serving system integrators and enterprises, with real overlap in device management, rules, and dashboards. Their emphases differ: Akenza is a Swiss platform with deep roots in smart buildings and bundled European connectivity, while TagoIO is a full-stack platform with a heavier application layer and a broader hardware connector library. Many evaluations shortlist both, so the details are worth walking through. Akenza is a self-service IoT platform from Akenza AG, founded in 2017 and headquartered in Zurich. It pairs a device type library and community decoders with a rule engine, data flows, and output connectors into enterprise systems (Azure IoT Hub, Google Pub/Sub, Kafka, Kinesis, InfluxDB, SQL databases, Grafana, and messaging tools). A distinctive feature is Connectivity as a Service: LoRaWAN connectivity purchased through the platform from integrated operators (Swisscom LPN, Loriot, Netmore, Cibicom, and others), plus SIM management. Dashboards cover charts, maps, tables, 3D floorplans, and signage screens; white-labeling starts on the Expert tier; and private-cloud deployment on Azure or GCP, including into your own cloud subscription, is available on Professional and Enterprise plans. Its client list leans smart building and facility management (ISS Switzerland, Zurich Insurance, Georg Fischer). In February 2026 it launched Genio, an AI assistant for querying building data. TagoIO is a full-stack IoT platform from TagoIO Inc. (Raleigh, North Carolina): 500+ device connectors, MQTT and HTTPS ingestion, LoRaWAN through network server integrations, time-series buckets with retention configurable to 9 years, Blueprint dashboards for fleets, serverless Analysis scripts in Node.js, Deno, or Python, Actions for rules, and TagoRUN white-label portals with a branded mobile app option. TagoDeploy provides dedicated instances in 12+ AWS regions. TagoIO is ISO 27001 certified and GDPR compliant. Connectivity models Akenza's bundled connectivity is genuinely convenient in its home markets: buy LoRaWAN network access per device through the platform, manage SIMs alongside devices, and invoice one vendor. The operator roster is Europe-centric, which is a strength for Swiss and EU deployments and a consideration elsewhere. TagoIO keeps connectivity independent of the platform. Projects bring any supported LoRaWAN network server, The Things Network or Industries, Actility, Everynet, Loriot, Senet, Swisscom, ChirpStack, Helium, and others, plus Sigfox, satellite (Myriota, Kinéis), and cellular paths, with network usage free on all plans. Integrators working across regions and operators keep one platform while networks vary per customer. Logic: data flows vs. serverless code Akenza's model chains rule logic and data flows visually, comparison and geofence rules, custom logic blocks, then routes outcomes to output connectors. It reaches external systems well, and heavier processing typically lands in the systems those connectors feed, Grafana for visualization, databases for analysis. TagoIO runs the processing inside the platform: Analysis scripts in Node.js, Deno, or Python execute serverless on triggers, schedules, or dashboard events, using ordinary libraries. Reports, integrations, scoring, business rules, and forecasts and predictions from telemetry stay in the platform rather than in downstream infrastructure. Teams with developers tend to feel this difference most. Dashboards and end users Both platforms build operator dashboards well; Akenza's 3D floorplans and signage screens fit its building focus, while TagoIO's Blueprint dashboards address fleet scale. For customer-facing delivery, Akenza offers white-labeling from its Expert tier ($599/month base); TagoRUN provides the branded portal with custom domain, user policies, and email templates, with the Custom Domain and Whitelabel add-on at $99/month and a branded mobile app option at published prices. Deployment and pricing Both offer paths beyond shared SaaS. Akenza's private cloud on Azure or GCP, deployable into your own subscription, is a real differentiator for organizations that must own the cloud account. TagoDeploy provides dedicated instances operated by TagoIO on AWS in 12+ regions from $850/month, each hosting as many applications as the project needs. Pricing structures differ enough to model carefully. Akenza combines a base fee plus $1.50 per device per month plus metering in Data Ingestion Units and Datapoint Storage Days. TagoIO combines plan tiers (free, Starter $49/month, Scale $199/month) with service usage: data transactions, storage, Analysis minutes, notifications, and end users, with no per-device charge. Depending on fleet size and message rates, either can come out ahead; run both calculators with real numbers. The bottom line Akenza is a natural fit for smart building and facility projects in Europe that value bundled LoRaWAN connectivity, SIM management, enterprise output connectors, and private-cloud deployment into their own Azure or GCP subscription. TagoIO fits when the application layer matters most: serverless code in standard languages, white-label portals at published add-on prices, longer data retention, a wider hardware connector library, and dedicated instances across 12+ regions. --- ## TagoIO vs. AWS IoT https://tago.io/compare/aws-iot Compare TagoIO and AWS IoT Core on architecture, dashboards, analytics, pricing, and time to production to find which IoT approach fits your project. AWS IoT and TagoIO solve the same underlying problem, getting data from devices into applications people can use, but they sit at different layers of the stack. AWS IoT is a set of cloud building blocks you compose into a solution. TagoIO is a full-stack IoT platform where the application layer is already built. Understanding that difference is most of the decision. AWS IoT is Amazon's family of managed services for device connectivity, anchored by AWS IoT Core (an MQTT broker with device registry, Device Shadows, and a rules engine that routes messages to other AWS services), alongside AWS IoT Greengrass for edge computing, AWS IoT SiteWise for industrial data, and AWS IoT Device Management for fleets. It runs at enormous scale and integrates deeply with the rest of AWS. TagoIO is a full-stack IoT platform: device connectors, time-series storage, dashboards, a serverless Analysis engine for custom code in Node.js, Deno, or Python, Actions for rules and notifications, and TagoRUN for white-label end-user portals. It runs on AWS infrastructure itself, with dedicated deployments available through TagoDeploy in 12+ AWS regions. TagoIO also maintains a native integration with AWS IoT Core, so the two are used together in many production solutions. TagoIO vs. AWS IoT comparison matrix | | TagoIO | AWS IoT | | --- | --- | --- | | Type | Full-stack IoT application platform | Cloud infrastructure services (PaaS building blocks) | | Device connectivity | MQTT, HTTPS, 500+ pre-built device connectors, LoRaWAN via network server integrations (TTN, Actility, Loriot, ChirpStack, and others) | MQTT, MQTT over WebSockets, HTTPS, AWS IoT Core for LoRaWAN, Amazon Sidewalk | | Dashboards | Built in, drag-and-drop, Blueprint dashboards for fleets | Not built in; typically Amazon Managed Grafana, QuickSight, or a custom app (SiteWise Monitor for industrial assets) | | Custom logic | Analysis engine: serverless scripts in Node.js, Deno, or Python, triggered by data, schedules, or dashboards | Rules engine routing to Lambda, Kinesis, Timestream, S3, and other AWS services | | End-user applications | TagoRUN white-label portal with user management, custom domain, and mobile app option | Build your own (Cognito, Amplify, custom web/mobile development) | | Multi-tenancy for your customers | Built in via TagoRUN user management and Access policies | Design and build your own tenancy model | | Edge | TagoCore, free and open-source edge engine | AWS IoT Greengrass, SiteWise Edge | | Deployment | Multi-tenant cloud (US and EU) or dedicated instances via TagoDeploy in 12+ regions | AWS regions worldwide, fully managed | | Pricing model | Free tier, then plan tiers (Starter $49/mo, Scale $199/mo) plus service usage; TagoDeploy from $850/mo | Pure usage-based: per connection-minute, per message, per rules action, per shadow operation | | Security and compliance | ISO 27001 certified, GDPR compliant, TLS 1.2+ in transit, AES-256 at rest | Extensive AWS compliance portfolio, X.509 device certificates, IAM | Architecture and what you build yourself AWS IoT gives you primitives. IoT Core terminates MQTT connections, authenticates devices with X.509 certificates, and routes messages onward. What happens next is up to you: storage in Timestream or S3, processing in Lambda, visualization in Grafana or QuickSight, and an end-user application built by your team. That freedom is the point. Teams with cloud engineers get exactly the architecture they want, at whatever scale they need. It also means a working proof of concept involves several services wired together, and a customer-facing product involves many more. AWS has been consolidating this layer: AWS IoT Analytics reached end of support in December 2025, AWS IoT Events follows in May 2026, and the Fleet Hub console retired in October 2025, with AWS pointing customers to general-purpose data services instead. TagoIO packages that application layer. A device connects through a connector or the API, data lands in time-series buckets with configurable retention up to 9 years, dashboards read it directly, and Analysis scripts handle whatever custom processing the solution needs. The pieces are integrated because they were designed together. Dashboards and end-user applications This is the largest practical difference. AWS IoT has no general-purpose dashboard; SiteWise Monitor covers industrial asset portals, and everything else means pairing AWS data services with Grafana, QuickSight, or a custom frontend. If your deliverable is an application your customers log into, plan for frontend development, user management, and tenancy design on top of the AWS services. In TagoIO, dashboards are part of the platform, and TagoRUN turns a project into a branded portal: your domain, your logo, your email templates, user signup, access policies, and an optional mobile app published under your name. For system integrators and OEMs whose deliverable is a finished application, this replaces a development workstream. Custom logic and analytics The AWS rules engine routes and transforms messages into more than 20 AWS services, which puts the full AWS data and ML stack at your disposal. Complex event logic lives in code you deploy and operate, usually Lambda. TagoIO's Analysis engine runs your scripts inside the platform, serverless, in Node.js, Deno, or Python, triggered by incoming data, schedules, or a button on a dashboard. Analytics reaches past dashboards as well, turning telemetry into forecasts and predictions inside the platform. For heavier pipelines, TagoIO data can flow out to external services, including AWS ones, through Actions and the API. Pricing model AWS IoT is metered per component: connection minutes, messages in 5 KB increments, shadow operations, rules actions, each billed separately, plus whatever downstream services the solution uses. Costs start near zero and track usage precisely, which rewards careful architecture and requires cost modeling at volume. TagoIO combines plan tiers with service-based usage: data input and output transactions, storage, Analysis minutes, notifications, and end users. The free tier covers 5 devices, Starter begins at $49/month, Scale at $199/month, and TagoDeploy dedicated instances start at $850/month post-paid. A cost calculator on tago.io estimates monthly cost from expected usage. The bottom line AWS IoT makes sense when you have cloud engineering capacity, need deep integration with AWS data and ML services, or are building a bespoke product at very large scale where infrastructure-level control pays off. TagoIO fits when the goal is a working IoT application, dashboards, alerts, custom logic, and a portal your customers use, without assembling and operating a dozen services. Many teams combine them, using the TagoIO integration with AWS IoT Core to keep AWS connectivity while getting the application layer from TagoIO. --- ## TagoIO vs. Microsoft Azure IoT https://tago.io/compare/azure-iot Compare TagoIO and Azure IoT (IoT Hub, IoT Central, IoT Operations) on application layer, dashboards, pricing, and deployment options. Azure IoT is Microsoft's portfolio of connectivity and edge services for building IoT solutions on Azure. TagoIO is a full-stack IoT platform where the application layer, dashboards, rules, custom code, and end-user portals, comes built in. The comparison depends on which Azure IoT product you mean, so it helps to lay out the portfolio first. Azure IoT Hub is the core service: a managed device gateway supporting MQTT, AMQP, and HTTPS, with device twins for state, jobs for fleet operations, and the Device Provisioning Service for zero-touch onboarding. Like AWS IoT Core, it stops at connectivity and message routing; storage, analytics, dashboards, and applications come from other Azure services or your own code. Azure IoT Central is Microsoft's hosted application platform on top of IoT Hub, with device templates, built-in dashboards, a rules engine, and per-device pricing. In February 2024, a message in the Azure portal announced IoT Central's retirement for 2027; Microsoft retracted it within a day and stated the service is not currently slated to retire. The service remains available, and buyers evaluating it can weigh Microsoft's public statements alongside where its investment is visibly going. Azure IoT Operations, generally available since late 2024, is that investment: a Kubernetes-based, Azure Arc-managed edge data plane aimed at industrial scenarios, built around an edge MQTT broker and OPC UA connectivity. TagoIO is a single platform covering device connectivity (MQTT, HTTPS, and 500+ device connectors), time-series storage, dashboards, serverless Analysis scripts in Node.js, Deno, or Python, Actions for rules and alerts, and TagoRUN white-label portals for end users. Dedicated deployments are available through TagoDeploy in 12+ regions. Device connectivity and provisioning IoT Hub is strong infrastructure: device twins are a mature pattern for state synchronization, DPS handles provisioning at fleet scale, and Device Update manages OTA. LoRaWAN is not a native Azure service, so LoRaWAN projects bring a partner network server and integrate it themselves. TagoIO connects devices through MQTT and HTTPS and through its connector library, which includes LoRaWAN network servers (The Things Network, The Things Industries, Actility, Loriot, ChirpStack, Helium, and others), Sigfox, and satellite providers such as Myriota and Kinéis. Payload parsers and a Live Inspector for debugging device traffic are part of the platform. Network usage is free; plans meter data input and output. Where the application gets built With IoT Hub, the application is yours to assemble: Stream Analytics or Fabric for processing, Power BI or Grafana for visualization, and custom development for anything customers touch. Organizations standardized on Microsoft tooling often want exactly this, because the IoT data lands in the same Fabric and Power BI stack the rest of the business uses. IoT Central includes operator dashboards and rules, and its REST API supports building beyond them, though customer-facing applications remain custom work. In TagoIO, dashboards, rules, and user-facing portals are platform features. Blueprint dashboards apply one layout across a whole fleet of devices. TagoRUN adds branded portals with user management, access policies, custom domains, and an optional mobile app under your own brand, which is the part Azure does not offer as a product at any layer. Custom logic Azure routes IoT Hub messages into Event Hubs, Functions, and the broader data platform. The pattern is capable and unbounded, and it means owning deployment and operations for each function and pipeline. TagoIO's Analysis engine runs custom scripts inside the platform without separate infrastructure, triggered by data conditions, schedules, or dashboard interactions. Platform analytics also cover forecasts and predictions on sensor data, not only dashboards. Teams that outgrow built-in limits can run External Analysis on their own compute while keeping the same platform APIs. Edge Azure has the deeper industrial edge story: IoT Edge modules and, more recently, IoT Operations on Arc-enabled Kubernetes with OPC UA support, aimed at factories with OT infrastructure and Kubernetes skills. TagoIO's edge component is TagoCore, a free, open-source IoT engine that runs on hardware from a Raspberry Pi to a cloud VM, distributed as a Docker image with a plugin architecture. It suits local collection and processing that syncs with the TagoIO cloud rather than Kubernetes-scale industrial deployments. Pricing model IoT Hub prices by capacity units and tiers with a free tier; IoT Central prices per device; IoT Operations is licensed through Arc. Storage, processing, and visualization services bill separately, so solution cost is the sum of several meters. TagoIO uses plan tiers plus service usage: free for 5 devices and 5 dashboards, Starter at $49/month, Scale at $199/month, and TagoDeploy dedicated instances from $850/month. Usage is measured in data transactions, storage, Analysis minutes, notifications, and end users, in one bill. The bottom line Azure IoT suits organizations committed to the Microsoft stack, teams that want IoT data inside Fabric and Power BI, and industrial deployments that can invest in IoT Operations at the edge. TagoIO fits when the deliverable is a finished IoT application, especially one your customers log into under your brand, and you would rather configure a platform than integrate a set of services. Both approaches run production fleets; the difference is how much of the solution you want to own as code. --- ## TagoIO vs. Blynk https://tago.io/compare/blynk Compare TagoIO and Blynk on mobile apps, device provisioning, LoRaWAN support, custom logic, and pricing for connected products and IoT solutions. Blynk and TagoIO both give hardware teams a cloud, dashboards, and branded applications without building them from scratch. Their centers of gravity differ: Blynk is strongest at shipping a branded mobile app for a connected product, especially on ESP32-class hardware; TagoIO is strongest as a full-stack platform for sensor data applications across LoRaWAN, cellular, satellite, and IP devices. Which one fits depends on what your product actually is. Blynk is a low-code IoT platform from Blynk Inc., founded in 2015 out of a Kickstarter campaign and headquartered in Miami. Its flagship capability is the mobile app builder: publishable, branded iOS and Android apps for your hardware, backed by device provisioning (Blynk.Edgent for WiFi onboarding), OTA firmware updates, web dashboards, automations, user and organization management, and firmware libraries with a very large Arduino and ESP32 community. Connectivity is MQTT and HTTPS, with LoRaWAN arriving through a The Things Stack integration, and recent partnerships adding satellite paths (Myriota, Deutsche Telekom NTN). Blynk reports SOC 2 compliance and 180B+ messages per month. TagoIO is a full-stack IoT platform from TagoIO Inc. (Raleigh, North Carolina): 500+ device connectors across LoRaWAN network servers, Sigfox, satellite, cellular, and IP; time-series storage with retention configurable to 9 years; Blueprint dashboards for fleets; serverless Analysis scripts in Node.js, Deno, or Python; Actions for rules; and TagoRUN white-label portals with user management and an optional branded mobile app ($99/month plus a one-time fee). TagoDeploy provides dedicated instances in 12+ AWS regions. TagoIO vs. Blynk comparison matrix | | TagoIO | Blynk | | --- | --- | --- | | Signature strength | Full-stack platform: data, dashboards, code, portals | Branded mobile apps for hardware products | | Device focus | LoRaWAN, Sigfox, cellular, satellite, NB-IoT, MQTT/HTTP devices | ESP32/Arduino-class WiFi and cellular devices, firmware-first | | Provisioning | Connectors, QR-code provisioning, device emulator | Blynk.Edgent WiFi provisioning, claiming flows, blueprints | | LoRaWAN | Maintained integrations with TTN/TTI, Actility, Everynet, Loriot, Senet, ChirpStack, Helium, and others | Via The Things Stack integration | | Custom logic | Analysis: serverless Node.js, Deno, Python scripts | Automations, webhooks, HTTP API; logic mostly in firmware or external services | | End-user apps | TagoRUN portal with custom domain and mobile app option | Branded app store apps; full white-label on Enterprise | | Data retention | Configurable up to 9 years | Tier-based, 1 week to 12 months | | Pricing | Free tier; Starter $49/mo; Scale $199/mo; usage-based services; TagoDeploy from $850/mo | Free 5 devices; Starter $29/mo; Prototype $99/mo; Production $199-1,099/mo; Enterprise custom | | Compliance | ISO 27001, GDPR | SOC 2 | Firmware-first vs. data-first Blynk's developer experience starts in firmware: include the library, flash an ESP32, and the device shows up with provisioning, OTA, and an app around it. For consumer-style connected products, that path from prototype to app-store product is what Blynk was built for, and its community and documentation reflect a decade of that use case. TagoIO's experience starts with data: connect a device through a connector or the API, parse its payload, store it, and build the application around it. Hardware diversity is the point; a TagoIO solution routinely mixes LoRaWAN sensors from several vendors, a cellular tracker, and an MQTT gateway in one application, which suits integrators and industrial monitoring more than a single-product consumer play. Application logic and analytics Blynk covers automations, alerts, and device control well, with heavier logic living in firmware or external services connected by webhooks and APIs. TagoIO includes a serverless compute layer, Analysis, where full scripts in Node.js, Deno, or Python run inside the platform: report generation, integrations with ERPs and ticketing systems, scoring and aggregation with Python libraries like pandas, and analytics that turn telemetry into forecasts and predictions. If your product's value includes server-side processing, this difference compounds over time; if the device and app are the product, it may not matter. Branded apps and portals Both deliver customer-facing experiences under your brand, differently. Blynk's branded mobile apps are the product; full white-label ships on the custom-priced Enterprise tier with private infrastructure options. TagoRUN centers on the web portal, custom domain, themes, user policies, with a branded mobile app as a published add-on ($99/month plus $2,000 one-time). For app-store-first products Blynk's path is more direct; for portal-first solutions with a mobile companion, TagoRUN covers both at published prices. The bottom line Blynk shines for hardware products whose center is a branded mobile app on WiFi or cellular ESP32-class devices, with an unmatched firmware-to-app pipeline and community. TagoIO fits sensor-data solutions across mixed hardware and networks, where dashboards, server-side code, long retention, and a white-label portal define the deliverable, with dedicated instances available as deployments scale. --- ## TagoIO vs. Cumulocity https://tago.io/compare/cumulocity Compare TagoIO and Cumulocity on device management, industrial protocols, multi-tenancy, deployment models, and pricing transparency. Cumulocity is one of the longest-running enterprise IoT platforms; TagoIO is a full-stack platform that grew up in the self-serve era. Both do serious production work, and they arrive at it from different directions: Cumulocity from telecom-grade device management sold through enterprise channels, TagoIO from a developer-accessible platform that scales into enterprise deployments. The right fit tracks how your organization buys and builds. Cumulocity began around 2012 as a Nokia Siemens Networks spin-off, spent 2017 to 2024 as Software AG's IoT platform, and completed a management buyout in January 2025, becoming independent Cumulocity GmbH (Düsseldorf), backed by Avedon Capital Partners, Schroders Capital, and Verso Capital. The platform is known for mature device management, lifecycle, firmware and OTA, connectivity monitoring, with wide industrial protocol support: MQTT, REST, native LwM2M, OPC-UA, and Cloud Fieldbus for Modbus, CAN, and Profibus. It offers true multi-tenancy with enterprise tenant hierarchies, white-labeling, streaming analytics, DataHub for offloading telemetry to data lakes, and deployment as multi-tenant SaaS, dedicated cloud, on-premises, or Cumulocity Edge, plus thin-edge.io, its Apache 2.0 edge framework. Its channel heritage runs through telecoms like Deutsche Telekom, Telia, Softbank, and NTT. Pricing is quote-based. TagoIO is a full-stack IoT platform from TagoIO Inc. (Raleigh, North Carolina): 500+ device connectors, MQTT and HTTPS ingestion, LoRaWAN through network server integrations, time-series storage with retention configurable to 9 years, Blueprint dashboards, serverless Analysis scripts in Node.js, Deno, or Python, Actions for rules, and TagoRUN white-label portals. TagoDeploy provides dedicated instances in 12+ AWS regions from $850/month, and pricing from the free tier up is published. TagoIO is ISO 27001 certified and GDPR compliant. Device management and protocols Cumulocity's device management depth is its calling card, and analysts have ranked it highly for years: fleet lifecycle at carrier scale, LwM2M natively, OPC-UA and fieldbus protocols for factory equipment, and connectivity monitoring built for operators reselling IoT. If your fleet includes industrial equipment speaking OPC-UA or Profibus, that support is native rather than integrated. TagoIO's device layer centers on the sensors and networks most solution builders actually deploy: LoRaWAN through maintained network server integrations (The Things Industries, Actility, Everynet, Loriot, Senet, Swisscom, ChirpStack, Helium, and others), Sigfox, satellite, cellular, and MQTT/HTTP devices, with per-device payload parsers, QR provisioning, and a Live Inspector for debugging traffic. The application layer Both platforms include dashboards and multi-tenant end-user delivery, with different accents. Cumulocity's Cockpit application and Web SDK support operator dashboards and custom applications, with deeper UI work happening in SDK development; its enterprise tenant model suits service providers running many customers on one installation. TagoIO treats the finished application as the default outcome: drag-and-drop dashboards, Blueprint dashboards across fleets, Analysis scripts as the backend, and TagoRUN portals, custom domain, user policies, branded mobile app option, at published prices. Custom code runs serverless inside the platform in ordinary languages rather than against a platform SDK, and analytics goes past dashboards, with forecasts and predictions built from telemetry. Deployment and buying model Cumulocity offers the fuller deployment menu, including true on-premises installation, which regulated and air-gapped environments sometimes require; TagoIO's option is TagoDeploy: dedicated instances operated by TagoIO on AWS in 12+ regions, each hosting multiple applications and tenants; an on-premises version is not currently available. On buying: Cumulocity is quote-based enterprise licensing; TagoIO is self-serve from free through published tiers, with sales conversations reserved for dedicated deployments. Buyers should also note Cumulocity's fresh independence, the January 2025 carve-out from Software AG, when assessing roadmap and support continuity, as with any platform in transition. The bottom line Cumulocity suits enterprises and service providers that need carrier-grade device management, native industrial protocols like LwM2M and OPC-UA, on-premises deployment, or telecom channel relationships, and that are comfortable with enterprise procurement. TagoIO fits teams that want to start building today, see published pricing, write application logic in standard languages, and deliver white-label solutions quickly, with dedicated regional instances available when scale and isolation demand them. --- ## TagoIO vs. Datacake https://tago.io/compare/datacake Compare TagoIO and Datacake on LoRaWAN workflow, dashboards, custom logic, white-labeling, and pricing for sensor monitoring projects. Datacake and TagoIO both serve teams turning sensor fleets into monitoring applications, and both are popular with system integrators deploying LoRaWAN hardware. They differ in depth of focus: Datacake is optimized around the LoRaWAN sensor-to-dashboard workflow, while TagoIO is a broader full-stack platform with a heavier application and custom-code layer. Both are good at what they emphasize. Datacake is a low-code IoT platform from Datacake GmbH, based in Vreden, Germany, and engineered and hosted from Germany. Its signature move is including its own LoRaWAN Network Server in every plan, so a project can run gateway-to-dashboard on Datacake alone, without The Things Network or ChirpStack. It ships a large library of ready-made device templates and JavaScript payload decoders, a drag-and-drop dashboard builder, a rules engine, multi-tenant workspaces, white-label web portals, a native mobile app with a white-label program, and its own cellular-backed LoRaWAN gateway hardware. TagoIO is a full-stack IoT platform from TagoIO Inc. (Raleigh, North Carolina): MQTT and HTTPS ingestion, 500+ device connectors across LoRaWAN, Sigfox, cellular, and satellite, time-series storage with retention configurable up to 9 years, Blueprint dashboards for fleets, serverless Analysis scripts in Node.js, Deno, or Python, Actions for rules, TagoRUN white-label portals with an optional branded mobile app, and TagoDeploy dedicated instances in 12+ AWS regions. TagoIO vs. Datacake comparison matrix | | TagoIO | Datacake | | --- | --- | --- | | LoRaWAN approach | Integrations with network servers: TTN/TTI, Actility, Everynet, Loriot, Senet, Swisscom, ChirpStack, Helium, and others | Built-in LoRaWAN Network Server in all plans, plus TTN, ChirpStack, Loriot, Helium integrations | | Other connectivity | MQTT, HTTPS, Sigfox, satellite (Myriota, Kinéis), NB-IoT, cellular | MQTT, HTTP API, cellular/NB-IoT paths, own gateway hardware | | Custom logic | Serverless Analysis: full scripts in Node.js, Deno, Python; general application backend | JavaScript payload decoders; Basic and quota-limited Advanced Rules | | Dashboards | Drag-and-drop plus Blueprint dashboards across fleets | Drag-and-drop dashboard builder with device templates | | Data retention | Configurable up to 9 years | 1 year (2 years with paid add-on) | | White-label | TagoRUN: custom domain, themes, user policies, mobile app option | White-label web portals from Light plan; white-label mobile app program | | Dedicated deployment | TagoDeploy dedicated instances, 12+ regions, from $850/mo | Not offered; German-hosted SaaS | | Pricing model | Free tier; Starter $49/mo; Scale $199/mo; usage-based services | Flat device tiers: free 5 devices; Hobby €25/mo; Light €159/mo; Standard €399/mo; Plus €659/mo | | Compliance | ISO 27001, GDPR | GDPR, German hosting | The LoRaWAN workflow For a pure LoRaWAN monitoring project with off-the-shelf sensors, Datacake's bundled network server is a real convenience: register a gateway, pick a device template, and data flows without operating a separate LNS. Its decoder library covers most common sensors, and flat per-device pricing keeps the quote simple. TagoIO's approach is network-server-agnostic. Projects bring their LNS of choice, community TTN, commercial Actility or Loriot, self-hosted ChirpStack, or a carrier's server, and TagoIO integrates through maintained connectors with per-device payload parsers. That is one more component in the diagram, and also freedom to choose or switch network infrastructure without changing platforms, which matters to integrators standardizing across customers with different network operators. When projects grow past dashboards The platforms diverge most in the custom logic layer. Datacake's rules engine covers alerting and automation for monitoring use cases, with quotas by plan for advanced rules; heavier processing is pushed outward through webhooks or Node-RED. TagoIO's Analysis engine runs full programs inside the platform, in Node.js, Deno, or Python with libraries like pandas, triggered by data, schedules, or dashboard interactions. Billing integration, custom reports, integration with ERPs, scoring logic: on TagoIO these are scripts, not external services. Forecasts and predictions from telemetry run inside the platform as well. The same applies to data lifetime: Datacake retains one year (two with an add-on), which fits monitoring; TagoIO retention is configurable to 9 years, which fits compliance-driven records and long-baseline analytics. White-label delivery Both platforms understand the integrator business. Datacake offers white-label web portals starting at its Light plan and a white-label mobile app program. TagoRUN provides the equivalent on TagoIO, branded portal, custom domain, user signup and access policies, custom email templates, and a mobile app under your own name, backed by Access Management policies for organizations and user groups. The bottom line Datacake is a strong fit for LoRaWAN-centric monitoring deployments that value the built-in network server, ready-made device templates, German hosting, and flat, predictable per-device pricing. TagoIO fits when the application will grow beyond monitoring: custom code as a first-class feature, longer retention, entity storage for structured data, and a path to dedicated instances. Integrators often try both with a real device; the workflow difference is visible within a day. --- ## TagoIO vs. Google Cloud https://tago.io/compare/google-cloud Google Cloud IoT Core was retired in August 2023. Compare building IoT on Google Cloud primitives with using TagoIO as a full-stack IoT platform. This comparison starts with a fact that changes its shape: Google Cloud IoT Core was retired on August 16, 2023, and Google has not introduced a first-party replacement. Google Cloud remains a serious option for IoT workloads, but today it means building on general-purpose primitives rather than adopting an IoT product. That makes the comparison less "platform vs. platform" and more "build vs. adopt." Google Cloud's current IoT guidance, documented in its Architecture Center, describes three patterns: run a standalone MQTT broker (EMQX, HiveMQ, or Mosquitto) on Compute Engine or GKE and bridge it to Pub/Sub; use a partner IoT platform, with ClearBlade IoT Core available on the Google Cloud Marketplace as an API-compatible successor to the retired service; or connect devices directly to Pub/Sub over HTTPS/gRPC for simple ingestion. Downstream, the data stack is a real strength: Pub/Sub into Dataflow, BigQuery, and Vertex AI is one of the strongest analytics pipelines available anywhere. TagoIO is a full-stack IoT platform: device connectivity over MQTT and HTTPS with 500+ pre-built connectors, LoRaWAN through network server integrations, time-series storage, dashboards, serverless Analysis scripts in Node.js, Deno, or Python, Actions for rules and notifications, and TagoRUN for white-label end-user portals. It is an adopted product rather than an assembled architecture. The device layer On Google Cloud, the device-facing layer is now yours to choose and operate. Pub/Sub has no MQTT endpoint, so MQTT devices need a broker you run or a partner platform you license. Device identity, registry, provisioning, OTA updates, and state management all come from that partner layer or your own build. Teams that already operate Kubernetes and want control over the broker can do this well; teams that expected an IoT Core-style managed front door now assemble one. TagoIO's device layer is part of the product: MQTT and HTTPS endpoints, device tokens, payload parsers, a device emulator, QR-code provisioning, and the Live Inspector for watching device traffic in real time. LoRaWAN, Sigfox, and satellite devices connect through maintained integrations with network providers, with network usage free on all plans. Dashboards, applications, and users Google Cloud's answer to visualization is Looker, Looker Studio, or Grafana over BigQuery, which serves internal analytics well. Customer-facing applications, user management, and any multi-tenant portal are custom software projects. TagoIO includes drag-and-drop dashboards, Blueprint dashboards that scale one layout across fleets, and TagoRUN, which turns a project into a branded portal with your domain, user signup, access policies, and an optional mobile app under your name. For system integrators delivering applications to clients, this is the difference between configuring and contracting a frontend team. Analytics and custom logic If your project's center of gravity is large-scale data analytics or machine learning, Google Cloud's Dataflow, BigQuery, and Vertex AI stack is hard to argue with, and it is a common reason teams choose GCP regardless of how devices connect. TagoIO handles the analytics most IoT applications need, aggregation, alerting logic, scheduled reports, integrations, and forecasts and predictions from telemetry, through Analysis scripts and Actions inside the platform, and its API supports exporting data onward when a heavier pipeline is justified. The two are not mutually exclusive: TagoIO can sit as the device and application layer feeding curated data into BigQuery. Pricing model Google Cloud bills each primitive by usage: Pub/Sub by data volume, Dataflow by compute, BigQuery by storage and queries, plus the separate cost of the MQTT broker infrastructure or partner platform license. Cost tracks architecture, and estimating it requires designing the architecture first. TagoIO prices by plan plus service usage: free tier with 5 devices, Starter at $49/month, Scale at $199/month, and dedicated TagoDeploy instances from $850/month, with usage measured in data transactions, storage, Analysis minutes, notifications, and end users. The bottom line Google Cloud makes sense when the organization is GCP-centric, device connectivity is simple or already solved, and the value of the project lives in downstream analytics and ML on BigQuery and Vertex AI. TagoIO fits when you want a maintained device layer and a finished application layer without operating brokers or building portals, which is the gap Google's own architecture guidance now fills with partners. Some teams use both: TagoIO for devices, dashboards, and end users, Google Cloud for warehouse-scale analytics behind it. --- ## TagoIO vs. Kaa IoT https://tago.io/compare/kaa Compare TagoIO and Kaa IoT (KaaIoT) on platform scope, open-source status, custom logic, white-labeling, deployment options, and per-device pricing. Kaa and TagoIO are both cloud IoT platforms with device management, dashboards, and per-project growth paths, and both court OEMs and solution vendors. A useful comparison starts by clearing up Kaa's licensing history, which still confuses evaluations, and then looks at where each platform puts its depth. Kaa is an IoT platform from KaaIoT Technologies, a US company. Two generations exist. The legacy Kaa 0.x, a monolithic Java platform with device SDKs, is open source under Apache 2.0 but effectively frozen at version 0.10 with archived documentation. The current Kaa 1.x ("Kaa Enterprise") is a different product: cloud-native microservices on Kubernetes, MQTT-centric, and commercially licensed rather than open source, though some components are on GitHub. It is offered as Kaa Cloud (multi-tenant, free up to 5 devices), KaaIoT-hosted dedicated instances, and self-hosted installations, including deployment into your clients' infrastructure. Capabilities include device and credential management, telemetry collection, configuration, command execution, OTA updates, alerts and rules, customizable dashboards, Keycloak-based identity, and white-labeling on hosted and self-hosted tiers. Pricing is per-device: free for 5 devices, then $99/month for 100 devices up to $625/month for 1,000, with contact-sales beyond. Packaged verticals include smart metering and energy, smart building, and agriculture. TagoIO is a full-stack IoT platform from TagoIO Inc. (Raleigh, North Carolina): 500+ device connectors, MQTT and HTTPS ingestion, LoRaWAN through network server integrations (The Things Industries, Actility, Everynet, Loriot, ChirpStack, Helium, and others), Sigfox and satellite support, time-series storage with retention configurable to 9 years, Blueprint dashboards, serverless Analysis scripts in Node.js, Deno, or Python, Actions for rules, and TagoRUN white-label portals with a branded mobile app option. TagoDeploy provides dedicated instances in 12+ AWS regions. TagoIO also maintains TagoCore, a free, open-source edge engine, and TagoTiP, an open, lightweight telemetry protocol for constrained devices. The open-source question Teams shortlisting Kaa because of its open-source reputation should confirm which Kaa they mean: the Apache 2.0 codebase is the dormant 0.x line, while the shipping 1.x platform is commercial. That is a legitimate model, but it changes the evaluation from "free software we control" to "commercial platform we license," the same category as TagoIO. On the TagoIO side, the cloud platform is proprietary and the open-source piece is at the edge: TagoCore, a free IoT engine distributed as a Docker image with a plugin architecture, running from a Raspberry Pi to a cloud VM. Neither vendor offers a current open-source version of its cloud platform; buyers who need one usually look at ThingsBoard CE instead. Platform depth Both cover the device-management fundamentals: provisioning, credentials, telemetry, commands, OTA in Kaa's case, dashboards, and alerts. The application layer is where TagoIO carries more weight. Its Analysis engine runs full serverless programs in Node.js, Deno, or Python inside the platform, turning it into an application backend for reports, integrations, business logic, and forecasts and predictions from telemetry; Kaa's rules and alerts cover automation, with heavier analytics typically routed to third-party integrations. TagoIO's connector library and LoRaWAN network-server coverage is also broader out of the box, which matters for mixed-hardware fleets; Kaa's MQTT-first model suits fleets whose devices you control. White-label and dedicated deployment Both platforms support the OEM story. Kaa offers white-labeling on its hosted and self-hosted tiers and will deploy into a client's infrastructure by arrangement, giving flexible ownership models. TagoIO packages the equivalent as products with published prices: TagoRUN portals with custom domain and branded mobile app, and TagoDeploy dedicated instances in 12+ AWS regions from $850/month, each hosting multiple applications and operated under an ISO 27001-certified program. An on-premises TagoIO is not currently available, so projects that must run in their own datacenter fit Kaa's self-hosted model better. Pricing shape Kaa meters devices: predictable per-device tiers from a free 5-device plan. TagoIO meters services: plan tiers (free, $49, $199) plus data transactions, storage, Analysis minutes, notifications, and end users, with no per-device charge. Low-message fleets with many devices can favor TagoIO's model; high-message fleets with few devices can favor per-device pricing. Real payloads through both calculators settle it quickly. The bottom line Kaa appeals when you want per-device pricing simplicity, self-hosting including deployment into client infrastructure, or its packaged verticals in metering, energy, and buildings. TagoIO fits when the application layer decides the project: serverless custom code, broad connector and LoRaWAN coverage, white-label portals at published prices, and dedicated regional instances without operating Kubernetes yourself. --- ## TagoIO vs. Losant https://tago.io/compare/losant Compare TagoIO and Losant on application enablement, workflows vs. serverless code, end-user experiences, edge, and pricing transparency. Losant and TagoIO occupy the same category, application enablement platforms that turn device data into finished products, and both serve OEMs and system integrators building customer-facing solutions. The comparison got a new variable in February 2026, when SUSE acquired Losant to fold it into its industrial edge portfolio. What follows compares the platforms as they stand, with that transition noted where it matters. Losant is an enterprise IoT platform founded in 2015 in Cincinnati and acquired by SUSE on February 19, 2026. Its centerpiece is the Visual Workflow Engine, a drag-and-drop logic builder that runs in the cloud, on gateways through the Gateway Edge Agent (a Docker container executing workflows locally, speaking Modbus, OPC-UA, BACnet, and similar protocols), and on constrained devices through the Embedded Edge Agent (WebAssembly). End User Experiences provide multi-tenant, white-labeled web applications with custom domains. Pricing is quote-based enterprise licensing, with SUSE's plans for packaging still taking shape. TagoIO is a full-stack IoT platform from TagoIO Inc. (Raleigh, North Carolina): 500+ device connectors, MQTT and HTTPS ingestion, time-series storage with retention configurable to 9 years, Blueprint dashboards, serverless Analysis scripts in Node.js, Deno, or Python, Actions for rules, and TagoRUN white-label portals with user management and a mobile app option. TagoDeploy provides dedicated instances in 12+ AWS regions, and TagoCore is its free, open-source edge engine. Pricing is published: free tier, Starter at $49/month, Scale at $199/month, TagoDeploy from $850/month. Application logic: visual workflows vs. serverless code This is the clearest philosophical difference. Losant expresses application logic as visual workflows, nodes wired on a canvas, one model spanning cloud, gateway, and embedded targets. Teams that think in flowcharts, and integrators who staff more solution engineers than programmers, tend to be productive in it quickly, and the cloud-to-embedded consistency is distinctive. TagoIO expresses logic as code. Analysis scripts are ordinary programs in Node.js, Deno, or Python, versionable in git, testable, using npm or Python libraries, triggered by data conditions, schedules, dashboard interactions, or API calls. Developers tend to prefer it for anything beyond routing: complex business rules, integrations with ERPs and billing, statistical processing with pandas, and analytics that turn telemetry into forecasts and predictions. Neither model is objectively ahead; they select for different teams. End-user delivery Both platforms treat the customer-facing application as a product feature rather than an afterthought, which sets them apart from infrastructure clouds. Losant's End User Experiences give full control over a white-labeled web application, pages, authentication, custom domains, inside the platform. TagoRUN takes a more packaged approach: branded portal with themes and custom domain, user signup and access policies, custom email templates, and a published-price mobile app under your own name. Experiences offer deeper UI control; TagoRUN reaches a branded deliverable with less build. Edge Losant's edge story is a strength: workflows run unchanged from cloud to Docker gateways to WebAssembly on embedded targets, and industrial protocol support lives in the Gateway Edge Agent. Under SUSE, this edge orientation is the stated strategic direction. TagoIO's TagoCore is a free, open-source edge engine distributed as a Docker image, running on hardware from Raspberry Pi upward with a plugin architecture for databases, parsers, and custom extensions. It covers local collection and processing synced to the cloud platform; deep industrial protocol work at the edge is more packaged in Losant's agents. Pricing and the transition question Losant has historically priced through custom enterprise quotes, without public tiers, and the SUSE acquisition leaves packaging and roadmap questions that prospective buyers should put directly to SUSE: pricing continuity, platform independence, and how Losant fits SUSE's Kubernetes-centered stack. TagoIO publishes its pricing, from a free tier through Starter and Scale to TagoDeploy dedicated instances, with usage measured in data transactions, storage, Analysis minutes, notifications, and end users, and a public cost calculator. For teams that want to model costs before a sales conversation, that transparency is itself a feature. TagoIO remains an independent company. The bottom line Losant suits enterprises and integrators invested in visual workflow development, deep white-label UI control, and industrial edge deployments, particularly those aligned with SUSE's infrastructure direction, and willing to work through quote-based licensing. TagoIO fits teams that prefer code over canvases, published pricing over quotes, and a managed platform with a self-serve start, from free prototype to dedicated regional instances, without an ownership transition to monitor. --- ## TagoIO vs. myDevices https://tago.io/compare/mydevices Compare TagoIO and myDevices (IoT in a Box, formerly Cayenne) on hardware bundling, customization, developer access, and channel models. myDevices and TagoIO both serve companies delivering IoT solutions to end customers, but they sell different things. myDevices sells packaged outcomes: pre-provisioned sensors, connectivity, and a monitoring app bundled for specific verticals. TagoIO sells a platform: the tools to build whatever application your project needs. The comparison is really about how much you want decided for you. A note for readers arriving from search: Cayenne, the free drag-and-drop IoT project builder many makers remember, was discontinued by myDevices, with end-of-life announced in September 2023. It was not open-sourced. Former Cayenne users looking for a home for custom hardware typically evaluate developer-oriented platforms; TagoIO's free tier (5 devices, 5 dashboards, MQTT and HTTP APIs) is one common landing spot. myDevices, Inc. is a Los Angeles-based company operating a "sensor enablement" business: a marketplace of 1,000+ pre-provisioned sensors, bundled LoRaWAN and cellular connectivity, pre-configured gateways, a Sensor App with dashboards and alerts, and services including provisioning, drop-shipping, and installation logistics. Its model targets channel partners, MSPs, and resellers deploying packaged vertical solutions, restaurant and pharma temperature compliance, hotel panic buttons, energy monitoring, under programs like IoT in a Box. In 2026 it repositioned around a "Sensor Lakehouse," streaming normalized sensor data into Databricks, Snowflake, and AI workflows. Its parent, Claranova, announced in November 2024 that myDevices was for sale, a process still under way as of mid-2026. Pricing runs from $5 per device per month pay-as-you-go to sales-led Platinum and Titanium tiers, with API access gated to the upper tiers. TagoIO is a full-stack IoT platform from TagoIO Inc. (Raleigh, North Carolina): 500+ device connectors, MQTT and HTTPS APIs open on every plan, time-series storage with retention configurable to 9 years, drag-and-drop and Blueprint dashboards, serverless Analysis scripts in Node.js, Deno, or Python, Actions for rules, analytics that turn telemetry into forecasts and predictions, and TagoRUN white-label portals with user management and a branded mobile app option. TagoDeploy provides dedicated instances in 12+ AWS regions. Pricing is published from a free tier through Starter ($49/month) and Scale ($199/month). Packaged solution vs. platform If your business is deploying the same vertical solution repeatedly, temperature monitoring for restaurant chains, for example, myDevices' bundle is a legitimate shortcut: hardware arrives provisioned, connectivity is included, the app exists, and field logistics can be contracted. The trade-off is the box's edges. Custom hardware, custom application logic, and custom user experiences are not the model, and API access starts at the sales-led Platinum tier. TagoIO starts from the opposite end. Any device that speaks MQTT or HTTP, or matches one of 500+ connectors, can connect on any plan, including free. The application, dashboards, alert logic, custom code, portal branding, is yours to shape, which is why OEMs and integrators with differentiated offerings build on platforms rather than bundles. Hardware, connectivity, and network server choices stay open: Dragino, Tektelic, RAK, Khomp, Netvox, Browan and other vendors' devices connect through maintained connectors, with LoRaWAN network servers from The Things Network to Actility supported. Developer access The clearest structural difference: TagoIO's APIs, SDKs (JavaScript and Python), CLI, and serverless Analysis engine are core features on every tier, because the product assumes builders. myDevices assumes deployers; its no-code onboarding is the feature, and programmatic access is an upper-tier add-on. Neither is wrong, they serve different buyers, but a team with developers will feel the ceiling quickly in one and not the other. Business stability Buyers weigh vendor circumstances alongside features. myDevices has been publicly for sale since its parent Claranova mandated the divestment in November 2024, which adds a question to long-term platform bets until ownership settles. TagoIO is an independent company operating under an ISO 27001-certified security program, with GDPR compliance and published SLAs. The bottom line myDevices works well for channel partners who want to resell finished vertical solutions, hardware, connectivity, app, and logistics from one vendor, without building anything. TagoIO fits teams building their own solution or product: open APIs on every plan, custom logic as a platform feature, white-label delivery under your brand, and room to differentiate. Former Cayenne users with custom hardware will find the free tier a familiar on-ramp. --- ## TagoIO vs. ThingsBoard https://tago.io/compare/thingsboard Compare TagoIO and ThingsBoard on hosting model, dashboards, custom logic, white-labeling, and total cost, including ThingsBoard CE self-hosting trade-offs. ThingsBoard and TagoIO are both full-featured IoT platforms with device management, dashboards, and rules. The core difference is the delivery model: ThingsBoard is best known as software you can host yourself, with commercial editions layered on top, while TagoIO is a managed platform with dedicated deployments available when projects need isolation. Which one fits usually comes down to how much infrastructure your team wants to own. ThingsBoard is an open-source IoT platform developed by ThingsBoard, Inc. The Community Edition (CE) is free under Apache 2.0 and self-hosted. The Professional Edition (PE) adds white-labeling, granular RBAC, customer hierarchies, platform integrations (LoRaWAN network servers, Sigfox, cloud services), and the scheduler, available self-managed or through ThingsBoard Cloud and managed private cloud. The stack is Java and Spring with Kafka, PostgreSQL, and optionally Cassandra or TimescaleDB, with ThingsBoard Edge for local processing. Version 4.x brought SCADA symbols, calculated fields, AI rule nodes, and a reworked pricing structure in early 2026. TagoIO is a full-stack IoT platform delivered as a managed service: 500+ device connectors, MQTT and HTTPS ingestion, time-series buckets with retention up to 9 years, drag-and-drop and Blueprint dashboards, serverless Analysis scripts in Node.js, Deno, or Python, Actions for rules, and TagoRUN white-label portals. TagoDeploy provides dedicated instances in 12+ AWS regions, and TagoCore is a free, open-source edge engine. TagoIO vs. ThingsBoard comparison matrix | | TagoIO | ThingsBoard CE | ThingsBoard PE / Cloud | | --- | --- | --- | --- | | Delivery | Managed cloud, dedicated via TagoDeploy | Self-hosted, you operate everything | Self-managed license or managed SaaS | | License / source | Proprietary platform; TagoCore edge engine is open source | Apache 2.0 | Commercial | | Protocols | MQTT, HTTPS, LoRaWAN / Sigfox / satellite via connector integrations | MQTT (incl. Sparkplug B), CoAP, HTTP, LwM2M, SNMP; OPC-UA/Modbus/BACnet via IoT Gateway | Same as CE plus platform integrations (LoRaWAN NS, Sigfox, AWS/Azure) | | Dashboards | Built in, Blueprint dashboards for fleets | Built in, large widget library, SCADA symbols | Same, plus white-label branding | | Custom logic | Serverless Analysis in Node.js, Deno, Python | Visual Rule Engine; deeper customization in Java/Angular | Visual Rule Engine plus PE features | | White-label end-user apps | TagoRUN portal, custom domain, mobile app option | Not included | White-labeling in PE/Cloud | | Ops burden | None (managed) or handled in TagoDeploy | Kafka, database tuning, upgrades, HA are yours | Reduced on Cloud; self-managed PE still yours | | Pricing model | Free tier; Starter $49/mo; Scale $199/mo; TagoDeploy from $850/mo; service-based usage | Free software plus your infrastructure and ops cost | PE from ~$10/mo (10 devices) to $499/mo (1,000); Cloud $49 to $749/mo tiers | | Compliance | ISO 27001, GDPR | Whatever you certify yourself | Vendor-operated for Cloud | Self-hosting is the real variable ThingsBoard CE is one of the most complete free IoT platforms available, and for teams with the skills and mandate to run their own stack, that is a real advantage: full control, data on your servers, no subscription. The cost shows up as operations, provisioning and tuning Kafka and databases, planning HA, applying upgrades, and owning security and compliance yourself. Features many production deployments want, white-labeling, granular RBAC, customer hierarchy, LoRaWAN integrations, sit in the paid PE tier, so a growing CE project often becomes a PE or Cloud subscription plus the infrastructure it runs on. TagoIO removes that layer entirely. The platform is operated for you under an ISO 27001-certified program, and when a project needs isolation, custom limits, or a specific region, TagoDeploy provides a dedicated instance without a migration to different software. Dashboards and end-user delivery Both platforms have strong dashboard builders; ThingsBoard's widget library is extensive and its SCADA symbols suit industrial HMI-style views. TagoIO's Blueprint dashboards address fleet scale, one layout serving hundreds of devices, and TagoRUN extends dashboards into a full end-user product: branded portal, user signup and access policies, custom email templates, and a mobile app under your own name. In ThingsBoard, white-labeling and customer-facing hierarchy are PE features, and a branded mobile app is your own build. Custom logic ThingsBoard's visual Rule Engine chains processing nodes and covers a lot without code; extending beyond it means Java development against the platform. TagoIO's model is code-first but serverless: write an Analysis in Node.js, Deno, or Python, and the platform runs it on triggers, schedules, or dashboard events. Platform analytics also carry past dashboards, turning telemetry into forecasts and predictions. Which model is more comfortable depends on your team; visual chains suit integrators who avoid code, scripts suit developers who want normal languages and libraries. The bottom line ThingsBoard fits best when self-hosting is a requirement or a strength: data sovereignty mandates, air-gapped environments, or teams that want Apache 2.0 software they control end to end, with commercial tiers available as needs grow. TagoIO fits when you want the platform operated for you, dashboards and white-label portals as product features rather than license tiers, and a path from free prototype to dedicated instance without changing software. Both are proven platforms; the decision is mostly about who runs the infrastructure and where the application layer comes from. --- ## TagoIO vs. ThingSpeak https://tago.io/compare/thingspeak Compare TagoIO and ThingSpeak (MathWorks) on data logging, MATLAB analytics, device management, dashboards, and paths from prototype to production. ThingSpeak and TagoIO overlap at the start of many IoT journeys, getting sensor readings into the cloud and onto a chart, and then serve different destinations. ThingSpeak is a data aggregation and analytics service with MATLAB built in, at home in research and prototyping. TagoIO is a full-stack platform for building production applications with dashboards, custom logic, and end users. Plenty of readers of this page have a ThingSpeak channel running right now and are deciding what production looks like. ThingSpeak is operated by MathWorks, the maker of MATLAB, and has run as a hosted service since its ioBridge origins in 2010. Its model is channel-based: each channel stores up to 8 fields of time-series data, written over a REST API or MQTT and read back into visualizations. Its defining feature is MATLAB analytics inside the service, run MATLAB code on incoming data without a local license, schedule analyses, and use toolbox functions for signal processing and statistics. The free tier covers small non-commercial projects (3 million messages per year, 4 channels); paid annual licenses in Standard, Academic, Student, and Home tiers scale by message units. It is hosted SaaS only, and device management is minimal by design: API keys per channel, no fleet lifecycle, OTA, rules engine, multi-tenancy, or white-labeling. TagoIO is a full-stack IoT platform from TagoIO Inc. (Raleigh, North Carolina): 500+ device connectors, MQTT and HTTPS APIs, LoRaWAN through network server integrations, time-series storage with retention configurable to 9 years, drag-and-drop and Blueprint dashboards, serverless Analysis scripts in Node.js, Deno, or Python (with libraries like pandas, numpy, and scipy), Actions for rules and notifications, and TagoRUN white-label portals with user management. The free tier includes 5 devices and 5 dashboards; paid plans start at $49/month. Where each shines ThingSpeak's fit is honest and specific: classrooms, research projects, and engineering prototypes where the analysis matters more than the application, and where MATLAB is already the working language. Nothing else puts toolbox-grade signal processing this close to a live sensor feed with this little setup, and the free tier's limits are generous for coursework and experiments. TagoIO's fit begins where a project needs to become a product: multiple device types, users who log in, alerts that reach the right people, branded delivery, and logic that runs continuously. Python Analysis scripts with numpy and scipy cover much of the numerical ground engineers use MATLAB for, in an open language, and the platform around them supplies what ThingSpeak deliberately omits: device management, a rules engine, user access policies, white-label portals, and analytics that turn telemetry into forecasts and predictions. The graduation path A common pattern: a ThingSpeak prototype proves the concept, then the project needs to monitor 40 sites instead of one, notify a maintenance team, and give a customer their own login. On ThingSpeak, each of those is outside the service's design; channels and message quotas also shape scale (8 fields per channel, minimum update intervals, message units per license). On TagoIO, they map to platform features: connectors and payload parsers for mixed hardware, Actions for notifications, Blueprint dashboards to reuse one layout across sites, and TagoRUN for customer access. Moving is mechanical rather than painful: both speak MQTT and REST, so device firmware changes are usually endpoint and payload adjustments, and historical CSV exports import into TagoIO buckets. Cost shape ThingSpeak's licensing is annual, message-metered, and cheap at small scale, with commercial use requiring the Standard license. TagoIO is monthly, free for 5 devices, then $49/month Starter and $199/month Scale, with usage measured in data transactions, storage, Analysis minutes, notifications, and end users. For a lone prototype both are inexpensive; the curves separate as devices, users, and application features accumulate. The bottom line ThingSpeak fits academic work, research logging, and MATLAB-centered analysis of sensor data, and it excels at exactly that. TagoIO fits when the project is becoming a product: fleets, users, alerts, branding, and custom server-side logic on an open stack. Prototype where the analysis is easiest; build production where the application layer already exists. --- ## TagoIO vs. Tuya https://tago.io/compare/tuya Compare TagoIO and Tuya on device platforms, white-label apps, hardware lock-in, data governance, and which fits consumer products vs. IoT solutions. Tuya and TagoIO both put a working IoT product within reach of teams that would never build a cloud from scratch, and both offer white-label applications. Beyond that, they diverge sharply: Tuya is a vertically integrated stack for shipping consumer smart devices on Tuya hardware modules, while TagoIO is a hardware-neutral platform for building sensor-data solutions. Most projects fit one clearly and not the other. Tuya (Tuya Inc., a Hangzhou-based company listed on the NYSE and HKEX) operates a developer platform that couples its own connectivity modules and chips with cloud services and ready-made consumer apps. A device maker picks a Tuya module (WiFi, Zigbee, BLE, Matter, Thread, cellular), defines the product in the console, largely no-code, across 2,800+ device categories, and ships with the Smart Life app or a rebranded OEM app under its own name; Smart App SDKs support fully custom apps. Tuya devices interoperate with Apple Home, Google Home, and Samsung SmartThings. Data centers span China, the US, Europe, and India, and Tuya Cube offers a containerized private-cloud edition of the platform for enterprises. Pricing combines IoT Core subscription editions with usage allowances, separately priced app tiers, and, structurally, module hardware sales. TagoIO is a full-stack IoT platform from TagoIO Inc. (Raleigh, North Carolina) that connects hardware from any vendor: 500+ device connectors across LoRaWAN, Sigfox, cellular, satellite, NB-IoT, and any MQTT or HTTP device. It provides time-series storage with retention configurable to 9 years, Blueprint dashboards, serverless Analysis scripts in Node.js, Deno, or Python, Actions for rules, TagoRUN white-label portals with a branded mobile app option, and TagoDeploy dedicated instances in 12+ AWS regions. TagoIO is ISO 27001 certified and GDPR compliant. Two different products The comparison is really between two business models. Tuya sells a path to market for consumer hardware: the module, the pairing experience, the app, and the cloud arrive as one decision, and a smart plug or lighting product can go from idea to shippable in weeks. The coupling is the value, and it is also the commitment: firmware, provisioning, and cloud are Tuya's, and moving off later means re-engineering the product. TagoIO sells the application layer above whatever hardware the project chooses. A solution might mix Dragino LoRaWAN sensors, a Tektelic gateway, a cellular tracker, and a legacy Modbus feed through an edge converter, and the platform's job is to store, process, and visualize that data, turn it into forecasts and predictions, and expose it to end users under your brand. Hardware independence is the point, which is why system integrators and OEMs with their own devices land here. Apps and portals Tuya's white-label OEM app is among the fastest branded-app paths in the industry for consumer device categories, with app-store publication and smart-home integrations handled. It is optimized for device control: switches, scenes, schedules, automation in the home. TagoRUN, TagoIO's white-label layer, is optimized for data applications: dashboards, alerts, reports, user roles and organizations, custom domain and email templates, with a branded mobile app option at published prices. A facility manager watching hundreds of sensors and a homeowner toggling a plug want different applications, and each platform builds the one it was designed for. Data governance Buyers in regulated industries and government-adjacent deployments routinely review data residency and jurisdiction. Tuya operates regional data centers and offers Cube private cloud as mitigations, and each buyer weighs its China-headquartered structure against project requirements. TagoIO runs on AWS with US and European regions on the multi-tenant platform, TagoDeploy instances in 12+ regions for data residency, ISO 27001 certification, and a GDPR data processing agreement. The bottom line Tuya is built for consumer smart-device makers who want the fastest route from product idea to an app-store-ready device, and who are comfortable building on Tuya modules and cloud. TagoIO fits sensor-data solutions on hardware you choose: monitoring, tracking, industrial and environmental applications delivered to your customers under your brand, with the freedom to change hardware vendors without changing platforms. Few projects genuinely sit between them; deciding which product you are building usually decides the platform. --- ## TagoIO vs. Ubidots https://tago.io/compare/ubidots Compare TagoIO and Ubidots on device connectivity, dashboards, white-label apps, custom code, and pricing models for IoT applications. TagoIO and Ubidots are close neighbors: both are application enablement platforms that turn sensor data into dashboards, alerts, and branded applications, both serve system integrators and product builders, and both price on a mix of capacity and usage. Because the overlap is large, the differences that matter are in the details of each layer. Ubidots is an IoT application platform from an independent company founded in 2013, headquartered in Medellín, Colombia. Devices send data over HTTP, MQTT, or TCP/UDP; UbiFunctions, its serverless engine, handles decoding and integrations; dashboards and events cover visualization and alerting; and white-label "Apps" give end users branded access with organizations, roles, and OAuth 2.0. Its data model organizes devices into variables, with a device defined as up to 20 variables. TagoIO is a full-stack IoT platform from TagoIO Inc., headquartered in Raleigh, North Carolina. Devices connect over MQTT and HTTPS or through 500+ pre-built connectors; Analysis runs serverless scripts in Node.js, Deno, or Python; dashboards include Blueprint dashboards for fleets; Actions handle rules and notifications; and TagoRUN provides white-label portals with user management and an optional branded mobile app. TagoDeploy adds dedicated instances in 12+ AWS regions. TagoIO vs. Ubidots comparison matrix | | TagoIO | Ubidots | | --- | --- | --- | | Device connectivity | MQTT, HTTPS, 500+ connectors incl. LoRaWAN network servers, Sigfox, satellite | HTTP, MQTT, TCP/UDP; plugins for TTN, LoRaWAN servers, Sigfox, Particle | | Serverless custom code | Analysis: Node.js, Deno, Python; triggered by data, schedule, or dashboards | UbiFunctions: Node.js and Python, for decoding and integrations | | Dashboards | Drag-and-drop; Blueprint dashboards scale one layout across fleets | Drag-and-drop, dynamic dashboards, SCADA-style widgets, heatmaps | | White-label / end users | TagoRUN portal: custom domain, themes, access policies, mobile app option ($99/mo + setup) | Apps: custom domain, branding, end-user organizations and roles, OAuth 2.0 | | Data model | Time-series buckets plus Entities for structured data; retention configurable up to 9 years | Devices and variables (20 variables per device unit); 6-month retention on Professional, longer on upper tiers | | Dedicated deployment | TagoDeploy dedicated instances, 12+ regions, from $850/mo | Enterprise plan with higher isolation options | | Entry pricing | Free tier (5 devices); Starter $49/mo; Scale $199/mo | Free STEM tier (non-commercial, 3 devices); Professional $99/mo with 50 devices | | Usage metering | Data input/output transactions, storage, Analysis minutes, notifications, end users | Datapoints in/out ($5/M in on Professional), extra devices $2 each, SMS and add-ons | | Compliance | ISO 27001, GDPR | Not publicly stated at the same certification level | Connectivity and decoders Both platforms assume LoRaWAN traffic arrives from a network server (The Things Stack, ChirpStack, carrier servers) rather than terminating LoRaWAN themselves. TagoIO maintains integrations for Actility, Everynet, Loriot, Senet, Swisscom, Kerlink, The Things Industries, Helium, and others, plus Sigfox and satellite providers, with connector-level payload parsers per device model. Ubidots handles the same job through its plugin system and UbiFunctions decoders. In practice, check both device lists for your exact hardware; pre-built support for your sensors saves more time than any other feature difference. Custom code The models are similar and both are genuinely useful: serverless code without your own infrastructure. TagoIO Analysis supports Node.js, Deno with npm imports, and Python with packages like pandas and numpy, and scripts can be triggered by Actions, schedules, dashboard buttons, or external API calls, which makes Analysis a general application backend, not only a decoder. TagoIO also puts analytics past dashboards, turning telemetry into forecasts and predictions inside the platform. UbiFunctions runs Node.js and Python and is aimed primarily at ingestion, parsing, and outbound integrations. Pricing structure Both combine a base plan with usage metering, and both reward estimating your data volume before committing. The units differ: Ubidots counts devices (with the 20-variable definition) and datapoints in and out; TagoIO counts data input and output transactions, storage, Analysis minutes, notifications, and end users, with capacity organized in Profiles. Variable-heavy devices can consume Ubidots device units faster than expected; chatty devices raise transaction counts on TagoIO. Model your fleet on both calculators with real payloads. The bottom line Ubidots is a polished application platform with a strong dashboard experience and mature end-user app features, and teams already comfortable with its device-and-variable model build good products on it. TagoIO fits when you want broader runtime options for custom code (including Python with scientific libraries and Deno), longer configurable data retention, ISO 27001-certified operations, and a growth path to dedicated instances in specific regions through TagoDeploy. For most buyers this comparison comes down to hardware connector coverage, pricing fit against real data volumes, and which platform's application model matches how your team builds. --- ## Which IoT Platforms Have the Best Partner Programs for System Integrators? https://tago.io/blog/iot-platform-partner-programs-system-integrators What separates a real IoT partner program from a badge and a discount code: margin structure, deal registration, sandbox access that holds a production-shaped pilot, and the questions that expose the difference before you sign. Every IoT platform has a partners page now. The logos rotate, the tiers have metal names, and the application form takes ten minutes. But "partner program" covers everything from a genuine wholesale business model to a badge and a discount code, and the parts that decide whether an integrator makes money are exactly the parts the page rarely spells out. The honest answer to which program is best is that it depends on what your practice sells. So the useful move is to know what a real program contains, and which questions expose the difference before anything is signed. What a real partner program includes Margin structure comes first because it is the business model. Programs pay partners three different ways, and how reseller programs and margins work breaks down the mechanics and the realistic ranges for each. The short version for this discussion: the margin type matters more than the margin percentage. A discount you can never raise is worth less than a wholesale rate under pricing you control, because in the second case you own the retail price and the invoice, and the difference compounds every year the customer renews. Deal registration protects the work you do before the sale. A registered opportunity should shield you from other partners and, more importantly, from the vendor's own direct sales team. A program without written deal registration is a program where your best prospect can become the vendor's house account, and the three months of pre-sales work you invested become a strongly worded email. Technical enablement and sandbox access separate programs built for integrators from programs built for logos. You need a development environment that costs nothing or close to it, training your engineers can finish in days rather than months, and access to real solution architects when a deal gets technical. If you cannot build a production-shaped proof of concept before paying, the program is marketing. Co-marketing ranges from a directory listing to funded case studies and shared leads. It is the least predictable component and deserves the least weight in your decision, but a vendor that funds a case study is signaling that it wants your vertical. Certification cuts both ways. A credential can shorten sales cycles when buyers recognize it, and hyperscaler badges often do. It can also be a revenue product the vendor sells to its own channel. Weigh the hours and fees against what the badge actually closes. Reading the margin before you sign Vendors rarely publish partner margins, which makes the market harder to read than it should be. The ranges are stable enough to plan around once you have seen a few agreements, and they are set out with the caveats in how reseller programs and margins work rather than repeated here, because two different numbers on the same site help nobody. What that post will not tell you is how the number behaves over time. Ask what the margin looks like in year three, after the introductory tier expires, and check the underlying platform pricing model while you are there: a partner margin sitting on top of consumption pricing you cannot predict is not a margin you can quote to a customer with confidence. The programs you will actually compare AWS and Microsoft run the largest partner networks in software, and their IoT services inherit that machinery: deep enablement, certifications buyers recognize, and marketplaces, in exchange for programs designed around consumption of their clouds. Specialist platforms such as Losant, Particle, Blynk, and ThingsBoard run smaller programs shaped around their own models, from hardware-plus-connectivity bundles to open-source support plans. Any of them can be the right answer for a given practice. The deciding variable is not the size of the network but the fit between the program's economics and how your business intends to bill. That is a different question from which platform is technically strongest to build on, which is covered in the platforms integrators actually resell. Questions to ask before joining Ask who owns the customer relationship and the billing, in writing. That single answer shapes your whole downstream contract, including the SLA you can offer, since you cannot commit to something the vendor has not committed to you. Ask what happens when the vendor's direct team finds your registered prospect. Find out whether the sandbox tier can hold a production-shaped pilot or only a demo. Check how many partners already work your region and vertical, because a saturated program is a referral queue with a logo. And ask what happens to your customers if you ever leave the program, because the answer tells you who the vendor believes the customer belongs to. How TagoIO approaches it TagoIO's program, at tago.io/partners, is built around the wholesale model described above. Partners deploy on the platform, white-label the customer-facing side through TagoRUN, and set their own retail pricing over published per-device rates. The free tier works as a real sandbox, so the proof of concept happens before any commitment, and there is no certification fee standing between an engineer and a running solution. There is a walkthrough of how system integrators build on TagoIO if you want to see the delivery side. It is a program shaped for integrators who want to own the customer and the margin, which is the same choice that sits at the center of the build or resell decision and of what a profitable managed service model looks like. The best partner program is the one whose economics match the business you are building. Read the terms the way you would read a customer contract, because that is what it is. Evaluating platforms for your practice? Talk to us or start free. --- ## How to Use an AI Assistant to Query Live IoT Device Data https://tago.io/blog/use-ai-assistant-query-live-iot-device-data A step-by-step walkthrough for querying live IoT device data with an AI assistant: opening TagoAI where the question lives, asking with specifics, checking the basis of every number, and raising the permission only when you want it to act. You already use an AI assistant for half your working day, and your devices already report the numbers you need: temperatures, tank levels, energy draw, last-seen timestamps. But the assistant knows nothing about your fleet, and the usual workaround of exporting a CSV and pasting it into the chat gives you an answer about the past. Live device data goes stale in minutes. The fix is a live, queryable connection to your devices, so every answer starts with a fresh read. On TagoIO there are two routes: TagoAI, the assistant built into the Admin with nothing to install, and the TagoIO MCP server, which connects an assistant you already use. This walkthrough covers the first route step by step, then shows where the second fits. For why grounding in live readings is the thing that matters, see querying your IoT data in natural language. What you need before you start A TagoIO account with at least one device sending data. That is the whole list for the TagoAI route, because the assistant ships inside the Admin. If you do not see it, check Profile Settings, then Services, then AI Provider. TagoAI is enabled or disabled per profile, and on EU-region profiles it is off by default, so you may need to turn it on. It also helps to arrive with a real question, one you would normally answer by opening three dashboards or asking an engineer. Real questions expose what the assistant can do faster than test prompts do. Step 1: Open TagoAI where the question lives The star icon in the Admin sidebar opens TagoAI from anywhere. If your question is about something specific, open it from that page instead: the top bar of the Analysis and Dashboards pages opens the assistant with context, meaning it sees what you are viewing. From a dashboard, "why is this widget empty" is a complete question. From an Analysis script, so is "why did this run fail last night." No IDs to paste, no schema to explain. Every session starts in Read mode. The assistant can list devices, inspect dashboards, review scripts, and read data, but it cannot create or change anything. For querying, that is exactly the mode you want, and it is worth knowing before you type: the floor is that it can only look. Step 2: Ask with the specifics you already know Plain English works, and specificity pays. "How are my devices doing" produces a survey. "Which cold-chain devices have not reported since midnight, sorted by site" produces the list you were going to build by hand. Name the devices, variables, sites, and time ranges you know, and let the assistant resolve the rest. Aggregation questions are worth a note, because this is where pasted-CSV workflows fail. When you ask for an average per site over last week, the math runs in code against live readings rather than inside the language model, which is not a reliable calculator. The question shapes that work best are worth skimming if you want a wider set of examples. Keep one task per chat. TagoAI keeps chat history so you can return to a thread, but history is capped at 20 chats per profile, and a chat that mixes four investigations is hard to reuse anyway. Step 3: Check the basis before you trust the number A grounded assistant is checkable, not infallible. Before a number leaves the chat and enters a report, ask which devices and what time range it used. The answer takes seconds to produce and tells you immediately whether the query matched your intent, or whether "last week" meant the calendar week when you meant the last seven days. Teams that build this reflex early trust the tool more, not less, because every answer carries its receipts. Step 4: Raise the permission when you want it to act Querying is where most people start. Acting is where the time savings compound. TagoAI has three modes, switched from the bottom of the chat panel. Read only fetches. Write can create and edit resources, such as drafting an Analysis script or building a dashboard, but cannot delete anything, which makes it the sensible ceiling for day-to-day work. Full adds deletion, and since deletions in TagoIO are not recoverable from the Admin, reserve it for tasks where you know exactly what you asked for. The controls around this are strict in the right places. The assistant never changes anything silently, it can only act within your own account permissions, and everything it does is recorded in the Audit Log with who ran it, when, and what changed. A typical session moves in one direction: ask in Read mode, confirm the plan, then raise to Write so the assistant can draft the Action or script the answer called for. The second route: your own assistant through the MCP server Some questions come up where you already work: in your code editor, in a longer analysis, in a conversation that spans more than TagoIO. For those, the TagoIO MCP server connects an external AI assistant to your account over the Model Context Protocol, with tools for devices, data, analyses, and dashboards. You ask mid-conversation, the assistant queries live, and the answer lands next to the work that prompted the question. The setup walkthrough for connecting an assistant over MCP covers that side in full. The two routes are complementary rather than either-or. TagoAI covers everyone working inside the platform with zero setup. MCP covers the people whose assistant is already open in another window. One habit applies to the MCP route specifically: the server acts with the token you give it, so scope that token to what the use case needs and keep sensitive accounts on read-only tokens. Habits that keep the answers trustworthy Three habits separate teams that keep using this from teams that try it once. Stay in the lowest mode that fits the task, and treat Full mode as an exception. Verify the basis of any number that leaves the chat. And decide deliberately who processes your data, which covers default provider agreements, bringing your own AI provider, and what that does to the monthly prompt limit. Those choices are laid out in querying your IoT data in natural language. The recorded webinar AI Meets IoT: A Practical Experience with TagoAI runs these steps live against a real account, including permission changes mid-session, and is worth thirty minutes before you roll the assistant out to a wider team. Ask the first question today The distance between reading this and getting your first grounded answer is one star icon. Open TagoAI in your Admin, stay in Read mode, and ask the question you have been answering by hand every Monday. If you do not have an account yet, start free and connect a device, or book a demo to walk through your use case with an engineer. --- ## What to Include in an SLA When Reselling an IoT Platform https://tago.io/blog/sla-reselling-iot-platform What a reseller SLA actually needs: the pass-through rule, a real uptime definition, durability separated from availability, support tiers you can hit, exit terms, and clause patterns you can hand to a lawyer. When you resell an IoT platform under your own brand, the customer signs a service level agreement with you and only you. Your logo is on the dashboards, your name is on the invoice, and your phone rings when data stops flowing at 2 a.m. But you do not run the infrastructure, and that single fact creates the rule every clause in your SLA must obey: you cannot promise your customer more than your platform promises you. Every commitment you write down is either backed by an upstream commitment or absorbed by you as unpriced risk. Most reseller SLAs fail because they were copied from templates written for companies that own their servers. Yours has to be built the other way around, starting from the document your vendor gives you. The pass-through problem Put the upstream SLA on the desk before you write a word of your own. If your platform commits to 99.9 percent uptime and you promise a customer 99.95, you have personally underwritten the difference: roughly 21 minutes of exposure every month with no infrastructure to fix and no upstream credit arriving when it fails. Taking that gap on deliberately, priced into your fee, can be a legitimate commercial decision, and how you price the managed service is where that decision gets settled. Taking it on because nobody did the subtraction is how resellers end up funding service credits out of margin. This is also why the vendor's own SLA belongs on your platform selection checklist. TagoIO publishes its SLA at tago.io/sla and holds ISO 27001 certification, which gives a reseller an audited baseline to build against instead of a verbal assurance. If you are still choosing what to build on, the platforms integrators actually resell are the ones that publish their numbers. Define uptime before you promise it An uptime percentage without a definition is decoration. Three parameters give it meaning. The measurement window comes first. 99.9 percent measured monthly allows about 43 minutes of downtime per month, while the same figure measured annually lets one brutal eight-hour outage disappear into eleven quiet months. Monthly is the honest window. Second, what counts as down: a full outage only, or degraded service too? If the API answers in 30 seconds instead of 300 milliseconds, your customer experiences an outage whether or not your definition admits it. Third, who measures and how it gets reported. A commitment the customer cannot verify breeds disputes, so name the monitoring source and commit to reporting incidents rather than waiting to be asked. Independent detection is also what lets you handle platform downtime as a managed service provider instead of learning about it from your own customer. Data durability is not availability These two get merged constantly and they are different promises with different stakes. Availability is whether the service responds right now. Durability is whether the data survives. A platform can be down for an hour and lose nothing, and your customer gets an apology and a credit. Lost data is a different category of failure, often unrecoverable and sometimes a compliance breach. Your SLA should carry separate language for each: an availability percentage with the definitions above, and a durability clause covering retention period, backup frequency, and what happens to data buffered during an outage. Ask your vendor the buffering question directly, because ingestion behavior during downtime is where durability quietly becomes availability's problem. Support tiers: commit to response, target resolution Response time is how fast a qualified person engages. You control that through staffing, so commit to it firmly. Resolution time depends on where the fault sits, and when it sits in the platform, the fix happens in infrastructure you do not operate. Keep resolution as a stated target. Tie both to severity. A Severity 1 incident, service down for all users, might carry a one-hour response around the clock and a four-hour restoration target. Severity 2, degraded but running, gets a four-business-hour response. Severity 3 covers questions and minor defects at one business day. Set numbers your team can hit during a bad week, because a commitment missed monthly costs more trust than a commitment never made. Writing the limits down is also what makes support survivable as you grow past ten customers. Maintenance windows and exit terms Planned maintenance announced in advance sits outside the uptime calculation, and your announced windows must sit inside your vendor's windows, so upstream maintenance never counts against you downstream. Commit to 72 hours of notice or more. Exit terms are the clauses buyers remember. State that the customer can export their data in a documented, machine-readable format during the contract and at termination, name the timeline, and name the cost, ideally zero. On a platform with full APIs this clause costs almost nothing to honor, and it wins deals against competitors whose silence on exit says everything. Ignoring exit costs until the exit is one of the most expensive mistakes integrators make, and the same question sits at the center of vendor lock-in. Clause patterns you can adapt These are language patterns to hand your lawyer, not legal advice. A few shapes that work: "Monthly Uptime Percentage means the total minutes in the calendar month, minus minutes of Downtime, divided by total minutes in the month. Scheduled Maintenance announced at least 72 hours in advance is excluded from Downtime." "Severity 1 incidents receive a response from a qualified engineer within one hour of report, 24 hours a day, seven days a week. Restoration targets are objectives, not guarantees." "Customer data remains the property of Customer. Within 30 days of termination, Provider will make all Customer data available for export in a documented, machine-readable format at no additional charge." "Service credits are calculated as a percentage of the monthly fee, capped at 100 percent of one month's fee, and constitute the sole remedy for availability failures." Build it back-to-back The method is mechanical. Lay the upstream SLA and your draft side by side and, for every downstream clause, write the name of the upstream clause that backs it or the margin that prices it. Anything backed by neither is a donation to your customer. Revisit the pairing annually, because your vendor's terms, your staffing, and your fleet size all move. This is also the document that changes when you shift from one-time projects to recurring services, since a subscription is a promise that renews every month. The gap between what you receive and what you promise never disappears. A good SLA shrinks it, prices it, and puts your name only on what you control. Start from a published baseline: TagoIO's SLA is at tago.io/sla. Book a demo or start free. --- ## Analytics Models for IoT: From Dashboards to Predictions You Can Act On https://tago.io/blog/analytics-models-for-iot How analytics models turn IoT sensor data into forecasts, anomaly scores, and time-to-threshold estimates: the four-step pipeline, which model family answers which question, why a fitted model beats an LLM at scoring telemetry, and what the research says about the payoff. Most IoT projects stop at the dashboard. Sensors stream temperature, vibration, pressure, and current into charts, and the team watches. Dashboards are good at their job: they show what happened. The problem is that nothing on a dashboard tells you a pump will trip next Thursday. Analytics models close that gap. They learn the normal behavior of each asset from its own history, then score every new reading against that pattern. The output is not another chart to interpret. It is a probability, a forecast, or a countdown you can act on: order the part, schedule the crew, shift the load before the peak. This article covers what an analytics model actually is, why a fitted statistical model beats a general-purpose AI model at scoring telemetry, which model family answers which question, and what published research says about the payoff. For the primer on descriptive versus predictive versus prescriptive analytics, start with what predictive analytics for IoT means. How IoT analytics works, from sensor to decision The pipeline runs in four steps: collect data from sensors, train a model on that history, run inferences on new readings, and act on the output. Collection is the part most IoT teams already have. Devices report on a schedule, the platform stores the readings as time series, and a few weeks of history accumulate. That history is the raw material for everything else. How much of it you need depends on the model and on the seasonality you are trying to capture, which is a question worth answering before you train anything. Training happens occasionally. The model reads the history once and extracts the structure: the daily cycle, the weekly cycle, the trend, the relationship between variables. Inference happens continuously and costs almost nothing. Each new reading is scored against the learned pattern in milliseconds. For the mechanics of where training runs and where scoring runs, see running machine learning on IoT data. The last step is where the value shows up. A forecast that crosses a limit can open a work order. An anomaly score can page a technician. A demand prediction can land on the same dashboard the operations team already uses, next to the live readings. What is an analytics model in IoT? An analytics model is a mathematical description of how a variable behaves over time, fitted to your own sensor data. Once fitted, it answers questions the raw data cannot: what this sensor will read next week, whether today's vibration pattern is unusual, how many days remain until a tank hits its limit. The model also changes what a KPI can be. Uptime last month and average temperature yesterday are backward-looking numbers; they describe a past nobody can change. A model produces forward-looking KPIs: probability of failure this month, days to threshold, a health score per asset, forecast demand with a confidence interval. Those are the KPIs a person can act on, because the event they describe has not happened yet. Confidence intervals matter more than they look. A forecast of "82 kWh tomorrow, between 76 and 88 with 95% confidence" lets you plan with known risk instead of a gut feeling. That is the difference between glancing at a chart and making a decision you can defend. Dashboards stay in the picture. The point is not to replace them but to change what they display: model outputs arrive as new variables, so the same screen that shows the last 24 hours can also show the next 7 days. | | Dashboards | Analytics models with good KPIs | |---|---|---| | Question answered | "What happened?" | "What is likely to happen, and how sure are we?" | | Time horizon | Past to present | Present to future | | Output | Charts a person interprets | Forecasts, probabilities, anomaly scores | | How action starts | Someone notices, then reacts | Alerts and work orders fire before the failure | | Decision support | Context and audit trail | Lead time and quantified confidence | Why use statistical models instead of AI to analyze sensor data? Because scoring sensor data is a numeric problem, and a trained model solves it for a tiny fraction of what general-purpose AI costs. Large language models are built for text and reasoning. Pointing one at raw telemetry means paying GPU prices, on every question, for arithmetic a fitted model runs on a CPU in milliseconds. The structural difference is where the reading happens. A statistical model reads your history once, during training. After that, each inference only touches the newest data points. An AI assistant asked "is this compressor healthy?" has no fitted model to lean on, so it would need to re-process the relevant data every single time. Nobody wants an LLM re-reading billions of data points because someone asked a question twice. Determinism is the other gap. A fitted model gives the same answer for the same input, with a confidence interval you can audit and explain to an operations manager or a regulator. Generative AI output can vary between runs, which is a poor fit for an alert that wakes someone at 3 a.m. | | Trained analytics models | General-purpose AI (LLMs) | |---|---|---| | Built for | Numeric time series | Language and general reasoning | | Hardware per inference | CPU | GPU clusters | | Cost per inference | Fractions of a cent | Orders of magnitude higher | | Latency | Milliseconds | Seconds | | Data handling | Trains once on history, scores only new points | Re-processes data on every question | | Repeatability | Deterministic, same input, same output | Output can vary between runs | | Explainability | Trend, seasonality, and thresholds you can audit | Difficult to audit | | Scaling to a fleet | Thousands of devices scored continuously at flat cost | Cost grows with every token processed | AI still earns its seat. Assistants are useful for building solutions, writing scripts, and explaining results, and you can ask your IoT data questions in plain language through one. The continuous, high-volume scoring of sensor data is a job for models, the same way you would not hire a consultant to add up a spreadsheet every hour. Which model fits which problem? Start from the question you need answered, then pick the family. Forecasting answers "what will this variable look like next?" Exponential smoothing (ETS) and Holt-Winters project a series forward by weighting recent history and its seasonal cycles. They are the workhorses of the field, covered in depth in Forecasting: Principles and Practice by Hyndman and Athanasopoulos at Monash University. MSTL decomposition handles series with several seasonal patterns at once, like energy use with both a daily and a weekly cycle. For how ARIMA, Prophet, and the neural options compare on a single series, see which forecasting model fits your IoT time series. Anomaly detection answers "is this normal?" K-Means clustering, a staple of Stanford's machine learning curriculum, groups an asset's operating states so new readings that fit no cluster stand out. DBSCAN finds density-based groups, which makes it useful for spotting the one device behaving unlike its peers. Isolation Forest separates outliers quickly even in large datasets. Detection and forecasting solve different problems, and reaching for the wrong one is a common early mistake. Drift detection answers "is this slowly getting worse?" EWMA control charts, documented in the NIST/SEMATECH e-Handbook of Statistical Methods, weight recent readings against a baseline and flag small, persistent shifts long before they trip a fixed threshold. Fouling filters, wearing bearings, and drifting calibration all look like this. Estimation and time to threshold answer "what drives this output, and how long do I have?" Multivariate regression estimates a target from its drivers, useful when the thing you care about has no direct sensor. Pairing a forecast with a threshold scan turns "the tank is at 63%" into "the tank reaches its limit in about 9 days," which is a maintenance schedule, not a chart. Does predictive maintenance actually pay off? Published numbers say yes. The U.S. Department of Energy's Operations & Maintenance Best Practices Guide estimates that a functioning predictive maintenance program saves 8% to 12% over a preventive program, and 30% to 40% for facilities coming from reactive, run-to-failure maintenance. Pacific Northwest National Laboratory maintains the same guidance: condition-based scheduling beats both the calendar and the breakdown. A peer-reviewed survey of predictive maintenance in Industry 4.0 reaches the same conclusion across dozens of studies. The technique works when the data pipeline behind it works. Deloitte's uptime and maintenance-cost figures are broken down in simplifying predictive maintenance, so they are not repeated here. One honest caveat: the gains depend on acting. A prediction nobody routes into a work order is just another chart. The action step of the pipeline is not optional. Getting started without a data science team Everything above can be built by hand with open-source libraries, somewhere to run them, and someone to maintain the pipeline. That is a real project: data extraction, retraining schedules, model storage, and wiring outputs back into alerts. TagoIO Analytics packages that pipeline into the platform your devices already report to. You pick a variable, a wizard trains the model on the data you already own, and predictions come back as regular variables. They land on dashboards, trigger Actions, and feed alerts with no ML code involved. The heavy steps, training and inference, run on the sight.tago.io service, while your data, dashboards, and Actions stay in your TagoIO account. The pipeline from the top of this article maps onto it directly. The model list maps onto the families above: Seasonal Forecasting (MSTL decomposition with ETS exponential smoothing), Demand Prediction (Prophet with driver forecasts), Estimation from Drivers (multivariate OLS regression), Quick Health Check (Isolation Forest), Continuous Monitoring (K-Means clustering), Peer Comparison (DBSCAN density clustering), Slow Drift Detection (EWMA control chart on a seasonal baseline), and Time to Threshold (Holt-Winters or AutoETS forecast with a threshold scan). If your sensors are already sending data, the training step starts from history you already own. See the models at tago.io/analytics, or book a demo to walk through one on your own readings. Sources - Hyndman, R.J. and Athanasopoulos, G. (Monash University), Forecasting: Principles and Practice, 3rd ed. - Taylor, S.J. and Letham, B., Forecasting at Scale (Prophet), PeerJ Preprints - Liu, F.T., Ting, K.M., and Zhou, Z.-H., Isolation Forest, IEEE ICDM 2008 - Ng, A. (Stanford University), CS229 Lecture Notes: The k-means clustering algorithm - NIST/SEMATECH, e-Handbook of Statistical Methods: EWMA Control Charts - U.S. Department of Energy, Operations & Maintenance Best Practices Guide, Release 3.0 - Pacific Northwest National Laboratory, O&M Best Practices: Maintenance Approaches - Predictive maintenance in Industry 4.0: a survey of planning models and machine learning techniques, peer-reviewed survey --- ## From Location to Intelligence: Catching What Happens to Your Cargo https://tago.io/blog/from-location-to-intelligence-cargo-anomaly-detection A tracker sealed in a steel container cannot hold a GPS fix. Temperature, light, and motion still can. How to reconstruct a shipment, forecast an ETA, and flag fraud from condition data. Cargo is worth more than it used to be, and it is getting hit harder. Verisk CargoNet put estimated 2025 cargo theft losses near $725 million, up 60 percent from 2024, with the average value per theft rising 36 percent to $273,990. Overall supply chain crime volume barely moved. Thieves simply got more selective about which trailers they open. Shippers have responded by buying visibility, and most of what they bought was a map. Trackers, a dashboard, a line on a map. That works until the freight goes into a steel box, where the coordinates stop arriving and the map stops being useful. It also answers a question that rarely matters once something goes wrong. Nobody files a claim over where a shipment was. They file it over what happened to it. The opportunity sits in the data most operations already collect and mostly ignore. A shipment leaves a fingerprint the whole way: how warm it got and how fast, whether the container was ever exposed to light, how many hours it spent moving versus sitting in a yard. That record survives the connectivity gaps. Read properly, it tells you when a problem started, what caused it, and which shipment on your board deserves attention first. This post is about reading it: reconstructing a journey, forecasting an arrival, and flagging fraud from condition data instead of coordinates. Steel blocks GPS, and no firmware fixes that A loaded steel container is a partial Faraday cage, and GPS is a weak signal to begin with. Satellite signals arrive at ground level close to the noise floor, and a few millimeters of corrugated steel is enough to kill them. Stack that container three high in a vessel hold and the receiver has nothing to work with. Placement helps at the margin. Door gaskets and vent openings leak radio energy, so a tracker mounted high in the door recess holds a fix better than one buried in the load. It does not solve the problem. On an ocean or multimodal leg, plan for gaps measured in hours or days. No firmware update fixes steel. The design question is what you do with the signals that still work. The signals that keep working inside the box Temperature, ambient light, and motion need no satellite. They keep reporting from inside the container, and together they carry most of the operational story. | Signal | What it tells you | What it cannot tell you | |---|---|---| | Temperature | When an excursion began, how fast it developed, whether the cause was a door or a failing unit | Where the shipment was | | Ambient light | A sealed container is dark. Light means it was opened, or the seal is compromised | Who opened it, or whether it was authorized | | Motion and tilt | Moving versus sitting still, dwell time at each stop, rough handling, orientation changes | Which yard it is sitting in | The Minew MTB04 carries all of these in one adhesive label, with onboard storage so readings survive the connectivity gaps rather than vanishing into them. That last detail matters more than it sounds: a buffered device gives you a continuous condition record even when the location record is full of holes. How do you know a container was opened if you have no GPS fix? By correlating signals rather than trusting any one of them. A light event on its own is weak evidence. A light event while motion reads "still," outside every scheduled stop window, with a temperature step starting minutes later, is a specific claim you can act on. This matters because physical seals are not the control people assume. Thieves pull door hinge pins and swing the door open from the hinge side, leaving the bolt seal untouched. The paperwork says intact. The light sensor says otherwise. The pattern to encode is a rule, not a threshold: light above baseline, motion below the movement threshold, timestamp outside the planned stop windows for that lane. Any of those alone produces noise. Together they produce a short list worth investigating. Estimating ETA from progress, not position Arrival is predicted from progress, which means an unreliable position trail is less of a handicap than it looks. The inputs that carry the ETA signal survive the gaps: - Motion duty cycle, meaning the ratio of moving hours to still hours on this leg compared with the lane's history - Dwell time at each node, which is where schedules mostly go wrong - Historical leg durations for the same origin, destination, carrier, and season - The location points you do get, at gate-in, gate-out, port arrival, and any open-sky stretch TagoIO Analytics turns those into a forecast without ML code. Seasonal forecasting uses MSTL decomposition with an automatically selected ETS model, so weekly and daily cycles in transit behavior get modeled instead of averaged away. Multivariate demand prediction runs Prophet fed by driver forecasts when you want weather or port congestion in the model. Time to Threshold runs its own Holt-Winters or AutoETS forecast, scans it for the crossing, and publishes an ETA in hours plus a severity tier you configure once. The outputs land as regular TagoIO variables: forecast values with upper and lower bounds, ETAs, severity tiers. Nothing downstream changes. Dashboards chart them, Actions trigger on them, and TagoRUN portals show them to your customers under your brand. An ETA that revises itself on every model run is worth more to a planner than a map pin that went stale fourteen hours ago. How does anomaly detection catch cargo fraud? By comparing a shipment against learned normal behavior instead of against a fixed limit. Fraud rarely produces one obviously bad reading. It produces a pattern that does not match how this lane usually behaves. That is the only angle that works on the fastest-growing category of loss. CargoNet's outlook flags theft by deception, where loads tendered to legitimate carriers get misdirected, sidestepping controls built around the tendering process itself. Deception does not break a seal or trip a threshold. It moves the load. Confirmed cargo theft incidents rose 18 percent in 2025 even as total crime volume stayed flat, which is what a shift toward this kind of scheme looks like in the numbers. TagoIO Analytics splits "is something wrong" into questions with a model built for each: - Is this reading unusual? An Isolation Forest scores each reading against the joint picture of normal. Temperature in range, light in range, motion in range, but that combination at 03:00 on a lane that never stops there: individually fine, collectively wrong. - Which operating mode is this? K-Means learns the normal operating modes across your fleet and scores each reading by distance from the nearest one. A leg that matches no known mode is worth a look. - Which unit is the odd one out? DBSCAN density clustering groups shipments that behave alike and flags the one belonging to no group. Forty labels on the same lane, one with a different motion signature, is how diversion and unit swaps surface. - Is something slowly going wrong? An EWMA control chart tracked against a seasonal baseline catches the slow creep that defeats fixed thresholds. This is the one that finds a reefer being nursed along for weeks before anything trips a compliance limit. You do not need labeled fraud history for any of this. The models train on the telemetry already sitting in your device buckets. Post-event analysis gives you cause, not just the alarm A real-time alert says the temperature crossed 8°C. Post-event analysis says which of two very different failures happened. A door opening produces a step: sharp rise, then exponential recovery once the door closes. A failing refrigeration unit produces drift: slow, monotonic, no recovery. Both trip the same compliance alarm. Only one is the carrier's fault, and the shape of the anomaly window tells you which. That distinction is the difference between eating the loss and recovering it. The same reconstruction feeds claims documentation with timestamped evidence, chain-of-custody records for regulated goods, carrier and lane scorecards built from dwell and excursion history, and a root-cause review that closes with a specific fix rather than a shrug. The same models on assets that never move Vending cabinets, stationary equipment, and fixed installations are the easier case. Location is already known, so every bit of value sits in the condition data. Motion where there should be none reads as removal or tampering. Light inside a closed cabinet reads as access. A temperature trend on a cooling unit reads as compressor health, and Time to Threshold converts that trend into days until it breaches, which is a maintenance window instead of a call from an angry customer. Same models, same wizard, no location required. What it takes to build The Minew MTB04 handles the sensing and the uplink. TagoIO ingests the payload, stores the history, and runs the models. Analytics setup is a guided wizard: pick devices, pick signals, choose how the model should behave, install. Everything after that is the platform you already have, because dashboards, Actions, the API, and white-label portals consume predictions the same way they consume sensor readings. Start with TagoIO Analytics for the models and TagoIO for logistics for the dashboards, geofencing, and integrations around them. The free plan gives you 5 devices and 5 dashboards, enough to wire up a label and watch the first forecast appear. Frequently asked questions Do GPS trackers work inside shipping containers? Not reliably. A loaded steel container acts as a partial Faraday cage and blocks the weak GPS signal. Trackers mounted high in the door recess, near gaskets or vents, hold a fix better than units buried in the load, but multi-day gaps on ocean and multimodal legs are normal. Condition sensors such as temperature, light, and motion keep reporting regardless. How can you tell if a shipping container was opened during transit? A sealed container is dark inside, so any ambient light reading above baseline indicates the container was opened or the seal is compromised. Light alone is weak evidence. Correlate it with motion state and the scheduled stop windows for that lane. Light while stationary and outside a planned stop is the pattern worth investigating, and it also catches hinge-pin entry that leaves the bolt seal intact. Can you predict shipment ETA without continuous GPS tracking? Yes. ETA comes from progress rather than position: motion duty cycle, dwell time at each node, historical leg durations for the lane, and the location fixes you do get at gates and ports. TagoIO Analytics forecasts the trend with MSTL plus AutoETS, and Time to Threshold scans a Holt-Winters or AutoETS forecast for the arrival crossing, publishing an ETA and severity tier as variables. What is anomaly detection in cargo monitoring? Scoring a shipment against learned normal behavior instead of fixed thresholds. TagoIO uses Isolation Forest for unusual joint readings, K-Means for operating-mode deviation, DBSCAN for peer comparison across shipments on the same lane, and an EWMA control chart for slow drift. Outputs are an anomaly score, a flag you can alarm on, and anomaly windows with start and end times. How do you detect cargo fraud with IoT sensors? By looking for patterns rather than single bad readings. Diversion shows up as a motion and dwell signature unlike peer shipments on the same lane. Tampering shows up as light events outside scheduled stops. Slow degradation that stays under every fixed threshold shows up as drift against a seasonal baseline. Peer comparison and drift detection catch these without any labeled fraud history. How much sensor history do you need before the models are useful? Train on three to four times more history than the range you want to predict, so a one-month forecast wants three to four months of data. Seasonal models need at least two full cycles of the pattern they learn. The TagoIO setup wizard checks your window and warns you when it is short. Can this monitor stationary assets like vending cabinets? Yes, and location becomes irrelevant. Motion where none is expected indicates removal or tampering, light inside a closed cabinet indicates access, and temperature trend indicates cooling-unit health. Time to Threshold turns that trend into days until a breach, which converts an outage into scheduled maintenance. Minew builds the sensing layer. TagoIO is the application layer that connects, stores, models, and shows it. See the MTB04 label on Minew's site, and TagoIO Analytics for the models described here. --- ## How to Handle IoT Platform Downtime as a Managed Service Provider https://tago.io/blog/handle-iot-platform-downtime-managed-service How managed service providers handle IoT platform downtime: detection before customers notice, honest communication, buffering at the edge, and the post-incident routine that turns outages into renewals. Every platform goes down eventually. Yours, your competitor's, the hyperscaler under both of you: uptime is a percentage, not a promise of immortality, and a managed service provider who has not planned for the bad hour is betting the customer relationship on luck. The reseller position has an uncomfortable structure: when the platform fails, the customer calls you, not the vendor, because your logo is on the portal. But downtime handled well is not just damage limitation. MSPs that run a disciplined incident routine consistently come out of outages with more customer trust than they went in with, because the outage is the one moment the customer actually watches you work. The routine below runs from before the incident to after it. Before: know about it first, and know what "down" means The unforgivable version of downtime is learning about it from a customer. Independent monitoring is the fix: an external check that exercises the real customer path, data in, API read, portal load, from outside the platform's own infrastructure, plus a subscription to the vendor's status page. TagoIO publishes its status at status.tago.io, and your monitoring should reference it automatically. The detection layer is also where the platform's own analytics and health checks help you: fleet-level anomaly detection distinguishes "one site's gateway lost power" from "ingestion stopped everywhere at once," which are different incidents with different first moves. Just as important is knowing what down means for your service specifically. An IoT stack fails in layers, sensors, connectivity, network server, platform, integrations, and your SLA's scope clauses should already map who owns each layer. We covered how those documents change as you move to recurring services. Most "platform down" tickets are actually connectivity or hardware, and diagnosing the layer in the first ten minutes decides whether you communicate an outage or dispatch a site visit. During: buffer where you can, communicate like you mean it Two properties of IoT soften most platform outages, and your architecture should exploit both. First, LoRaWAN network servers and most gateways buffer or retry uplinks, and devices keep measuring regardless, so a storage-layer outage usually means delayed data, not lost data. Knowing your stack's actual buffering behavior, how long, at which layer, turns "is my data gone?" into a question you can answer precisely, and it is a question every customer asks. Second, edge components keep local logic alive: where a use case genuinely cannot tolerate cloud gaps, an on-premises layer like TagoCore keeps local alerting and control running through a cloud incident, and that belongs in the design conversation for critical deployments, not in the apology afterward. Then the part MSPs underestimate: communication cadence beats communication content. The routine that works is fixed and boring. Acknowledge to all affected customers within the first 30 minutes, before they open tickets, with what you know, what still works, and when the next update comes. Update on the stated schedule even when the update is "no change." Never speculate on a fix time you do not control; relay the vendor's estimate, labeled as such. Customers forgive downtime with startling consistency. They do not forgive silence. During: what your SLA was for The incident is where the paperwork earns its keep. Severity levels route the response, scope clauses keep you from apologizing for a carrier outage, and the back-to-back alignment between your customer SLA and your vendor SLA decides whether a bad month costs you margin or just credits that offset upstream. If an incident reveals a gap between the two documents, that is a contract fix, not just an operational lesson. After: the routine that converts outages into renewals When service restores, three steps close the loop properly. Verify data integrity before declaring victory: check the buffered uplinks arrived, backfill gaps where the stack allows it, and tell customers what the data record actually shows for the outage window. Send a short post-incident note within 48 hours, what happened, what the impact was, what changes, in plain language, unprompted. Apply service credits proactively if the SLA triggers them; the invoice arriving already-corrected is worth more goodwill than the credit itself. Then feed the incident back into the machine: does monitoring need a new check, does a critical customer need an edge component, does the support tier pricing reflect who actually consumed the incident hours? The quiet conclusion An MSP cannot promise a platform never fails. What an MSP can promise, and get paid for, is that failure is detected in minutes, diagnosed to the right layer, communicated on a schedule, buffered where the architecture allows, and closed with an honest accounting. That is a product, and it is one of the strongest differentiators a managed service can sell, precisely because most competitors improvise it. It also starts with a vendor whose baseline you can trust: published status, published SLA, audited operations. TagoIO gives resellers that foundation. Book a demo or start free. --- ## How to Evaluate Data Residency Options in an IoT Platform https://tago.io/blog/evaluate-data-residency-iot-platform How to evaluate data residency in an IoT platform: what residency does and does not mean, the five questions that expose weak answers, and how region choice decides which customers you can serve. Data residency used to be a question only lawyers asked, and IoT teams could pick a platform without knowing which continent their data slept on. That era is over. European customers ask where telemetry is stored before they ask about features, public tenders make residency a pass-fail gate, and sectors from health to utilities carry national rules about data leaving the country. For anyone selling IoT services, the platform's residency options quietly define your addressable market: a platform with one US region is a ceiling on who you can sell to, no matter how good the product is. Evaluating residency properly comes down to a handful of questions, and they separate real answers from marketing ones. What residency is, and what it is not Data residency is the physical and legal location where your data is stored. It is related to, but not the same as, three neighbors it gets confused with. Data sovereignty is whose laws apply to the data, which follows from residency but also from who operates the infrastructure. Data ownership is who has rights over the data, a contractual question we covered in who owns your IoT data. And GDPR compliance is a legal regime that constrains transfers but does not by itself require EU storage. A vendor who answers a residency question with "we are GDPR compliant" has answered a different question, and that substitution is worth noticing when it happens. The five questions that expose weak answers First: which regions can our data be stored in, and can we choose per deployment? The strongest answer is a documented list of regions with customer choice at profile or tenant level. TagoIO, for example, operates separate US and European clusters and the choice is yours at signup. If the answer is one region, that is a market ceiling, not a dealbreaker, but price it in. Second: does all of the data stay in the region, or only the telemetry? This is where weak residency stories fall apart. Time-series data may sit in Frankfurt while account metadata, file storage, or backups quietly live elsewhere. Ask specifically about metadata, backups, and logs, and get the answer in writing. Third: does data transit outside the region during processing? Some platforms store in-region but process, run analytics, or route notifications through services elsewhere. If your customers care about residency, they usually care about transit too. This includes the AI layer: if the platform runs analytics and AI on your data, ask where those workloads execute and whether any of it leaves the region. A platform that runs its intelligence inside the same infrastructure as the storage has a much cleaner answer than one that ships data to third-party model APIs by default. Fourth: what happens if we need to move regions later? Migration between regions is the residency version of vendor lock-in: possible everywhere, painful in different amounts. Documented export APIs and a stated migration path are the honest answer; "contact support" is a flag. Fifth: who can access the data, from where? Residency of bytes matters less to some regulators than residency of access. Support staff jurisdiction, subprocessor lists, and the legal entity you contract with all belong in the diligence, and a platform with a signed DPA and an ISO 27001 certification, as TagoIO carries, gives your compliance reviewer an audited baseline instead of assurances. Matching the requirement to the deployment Not every deployment needs the strictest answer, and over-specifying residency costs money too. A useful sorting: commercial-sensitivity deployments (most industrial monitoring) need a region choice and a DPA. Personal-data deployments (anything touching occupants, workers, vehicles) need region choice, transit answers, and the GDPR machinery, the full checklist from our GDPR evaluation guide. Regulated-sector deployments (health, utilities, government) need all of the above plus sector rules, and sometimes they genuinely need on-premises components, which is where an edge option like TagoCore keeps the sensitive processing local while the rest of the fleet stays in the cloud. If you resell IoT services, do this sorting for your customers before they ask. A reseller who can say "your data stays in Europe, here is the document" wins tenders against competitors who need three weeks to find out. The test that settles it Ask the vendor to show, not tell: a signed DPA template, the region list in public documentation, the subprocessor list, and the certification. Ten minutes of documents beat an hour of assurances. Residency done right is boring, and boring is exactly what your customer's compliance team is buying. TagoIO runs European and US clusters, signs DPAs, and is ISO 27001 certified, with the details public on the trust page. Book a demo or start free. --- ## What a Good IoT Dashboard for Facility Management Actually Looks Like https://tago.io/blog/iot-dashboard-facility-management What a good facility management IoT dashboard actually contains: the four views that matter, why layout follows the building, and why the best facility UIs now lead with forecasts and flagged anomalies instead of raw charts. Facility managers do not have a data problem. A mid-size commercial building with submetering, HVAC monitoring, occupancy sensors, and leak detection produces more readings in a day than anyone will ever look at, and most facility dashboards respond by showing all of it: walls of gauges and charts that demo beautifully and go unopened by week six. The dashboards that survive daily use are built backwards from a different question. Not "what data do we have," but "what does the person opening this need to decide in the next ten minutes?" In practice that produces something specific, and it explains why the best facility UIs now lead with intelligence rather than charts. The four views a building actually needs A facility dashboard that works is not one screen. It is a small hierarchy, usually four levels deep. The portfolio view answers "which building needs me today" for operators with more than one site: a map or list where each building carries a single status, calm, watch, or act, computed from everything below. The building view shows the systems that spend money and cause complaints, energy load against the expected curve, HVAC health, water, comfort zones, on one screen with no scrolling. The system view is where a technician drills into a specific air handler or meter with full history. And the compliance view, temperatures for food areas, water safety checks, is less a dashboard than an automatic report, because its real audience is an auditor. What every level shares: status first, numbers second. "Chiller 2: attention needed" beats a gauge showing 78.4 in a font nobody can read from a hallway. Layout follows the building, not the database The classic mistake is organizing the dashboard by data source, a LoRaWAN page, a Modbus page, a BMS page, because that is how the integration was built. Facility staff think in floors, zones, and systems, so the dashboard should too. On TagoIO this is configuration rather than code: widgets bound to device groups by tags like floor, zone, and system, so the same blueprint serves every building in the portfolio, which is exactly the template discipline that keeps a growing portfolio maintainable. The real shift: dashboards that think, not just show Everything above has been the standard advice for years, and it is no longer enough, because even a well-organized dashboard only shows the past. The energy chart shows consumption climbing after it climbed. The comfort panel shows a zone hot after the complaints arrived. Someone still has to open the screen, notice, interpret, and react, and at portfolio scale nobody reliably does. The facility dashboards worth building in 2026 put the intelligence in the UI itself. The energy widget carries a forecast band, so today's load is judged against where it should be, and the month-end cost projection updates live. The chiller panel does not just chart vibration; it flags that the pattern started drifting from its learned baseline nine days ago and estimates the window before it becomes a failure, the same predictive maintenance logic that manufacturing runs. The water view converts a 2 a.m. flow anomaly into a leak alert with a location instead of a chart someone might scan on Monday. And the operator's morning starts with a short queue of flagged items with recommendations attached, not a wall of green gauges hiding one amber one. On TagoIO, this layer is not a separate BI product bolted on afterward. Analysis scripts and built-in AI and analytics run forecasting and anomaly detection inside the platform, and the results render in the same widgets as the live data: forecast bands on the energy chart, anomaly flags on the equipment panel, a recommendation card above the fold. The facility manager never learns what a model is. They just stop discovering problems late. The techniques underneath are the ones we covered in forecast-based alerts and energy forecasting. Alerts: the dashboard for people who do not open dashboards Most facility staff interact with the system through their phone, not the wall screen, so the alert stream is the dashboard for them. The bar to hold: every alert should carry what happened, where, how bad, and what to do next, and forecast-based alerts should outnumber threshold alerts over time, because "Zone 3 will breach comfort range around 14:00" creates an option while "Zone 3 breached at 14:00" creates an apology. Where to start Begin with one building, the four views, and intelligence on the two systems where predictions pay fastest: energy, because the forecast versus actual gap is money every day, and the single most complaint-prone HVAC asset, because early drift detection converts emergencies into scheduled work. Then template it across the portfolio. TagoIO ships the dashboard layer, the analytics and AI, and connectors for the usual facility hardware, so the build is configuration rather than a software project. There are dashboard templates to start from, and the buildings solution page shows real deployments. Book a demo or start free. --- ## The Fastest Way to Add a New Device Type to an IoT Platform https://tago.io/blog/fastest-way-add-new-device-type-iot-platform The fastest path to adding a new device type to an IoT platform: check the connector library first, then decoder, template, and test, in under an hour for supported hardware and under a day for anything else. Adding a new device type is the most repeated task in any IoT operation, and its cost decides more than teams expect. A customer asks for a new sensor, a hardware vendor discontinues a model, a new use case needs a different measurement, and each time, someone has to make an unfamiliar device speak to the platform. Do it the slow way and every addition is a small engineering project with custom parsing code that someone maintains forever. Do it the fast way and it is an hour of configuration. Across a growing fleet, that difference compounds into the gap between a catalog you extend freely and one you avoid touching. The fast path runs in the order below, which is also the order that saves the most time. Step 0: check the connector library before writing anything The fastest decoder is the one that already exists. Mature platforms maintain libraries of pre-built device connectors with the payload decoding, variable naming, and units already configured. TagoIO's connector library covers hundreds of devices from the major LoRaWAN and cellular vendors, and a supported device goes from box to dashboard in minutes: pick the connector, register the serial number, data arrives decoded. This step also belongs in procurement, not just engineering. When two sensors measure the same thing and one has a pre-built connector, the connector is worth real money over the device's life. Integration effort is a hardware selection criterion, the same way battery life and radio performance are. Step 1: get one real payload If the device is not in the library, resist the urge to start from the datasheet. Get one physical device sending real uplinks first, because datasheets describe intent while the payload is fact, and the two disagree more often than vendors admit. Firmware versions change byte orders, fields shift, and a decoder written purely from documentation fails against production traffic in ways that cost an afternoon of confused debugging. Step 2: write the decoder once, as configuration A payload decoder does one narrow job: bytes in, named variables with units out. Keep it that narrow. On TagoIO the decoder lives in the connector as a small JavaScript function, and most LoRaWAN vendors publish reference decoders that need only light adaptation. The discipline that pays off later: standardize variable names and units across device types. If three temperature sensors from three vendors all emit "temperature" in Celsius, everything above the decoder (dashboards, alerts, analytics) becomes reusable. If they emit "temp," "tc," and "temperaturef," every layer above pays the tax forever. Step 3: template the application layer The decoder makes data legible; the template makes it useful. Bind the new device type to a dashboard blueprint, default alerts, and any analysis scripts once, so the second unit of this device type inherits everything. This is the same build-once-apply-everywhere discipline that makes fleets scalable, applied at the device-type level. There is a bonus that arrives free with standardization: the platform's analytics and AI treat the new device type like every other one. Anomaly detection baselines start learning its behavior, forecasts run on its variables, and the new sensor shows up in the same intelligent UI as the rest of the fleet, with no extra pipeline work, precisely because the decoder emitted standard names and units. Step 4: test with the field in mind Before declaring the type supported, run one device through the unglamorous cases: a low battery report, a lost-connection gap, a value at the edge of the sensor's range, and, for LoRaWAN, a confirmed downlink if the device accepts configuration. Ten minutes of this catches what the demo path misses. What the numbers should look like On a platform with a connector library and template support, a supported device type costs under an hour, and an unsupported one costs half a day to a day, most of it decoder verification. If additions routinely cost more, the friction is usually structural: no library, no template layer, or an API that makes bulk registration painful, and that is a platform evaluation finding, not a fact of IoT life. A device catalog you can extend in an hour changes how the whole business behaves: sales says yes to hardware requests, operations swaps discontinued models without drama, and the fleet grows by configuration. TagoIO ships the connector library, the template layer, and the analytics that light up on top. Book a demo or start free. --- ## How to Scale Your IoT System Integrator Business Beyond 10 Customers https://tago.io/blog/scale-iot-integrator-business-beyond-10-customers Ten customers is where IoT system integrator growth stalls: founder-led delivery, custom everything, and manual monitoring stop scaling. The operating model that gets past it: templates, tiers, automation, and intelligence. Ten customers is a strange milestone for an IoT system integrator. It proves the business works, and it is exactly where growth usually stalls. The first ten arrived through founder relationships, got founder-quality attention, and each one received a solution built with care by the same two or three people. But the model that won those ten cannot win thirty, because it scales with headcount and heroics rather than with systems. Getting past ten is not a sales problem. It is an operating model change, and the firms that make it share four specific habits. Habit 1: sell the product you already built At ten customers, look backward before you look forward: which three deployments were the same solution wearing different logos? That overlap is your product. Package it, name it, price it, and sell that instead of bespoke scope. Tank monitoring for fuel distributors. Cold-room compliance for food logistics. Submetering for commercial buildings. Whatever your pattern is, the discipline is saying no to work outside it, because every bespoke deal resets your delivery cost to customer-one levels. This is the difference between a profitable managed service model and a custom shop with a subscription invoice. Habit 2: make deployment a checklist, not a project The firms that scale treat delivery as manufacturing. Device provisioning is an API call or bulk import. Dashboards come from templates. Alerts and analysis scripts are parameterized. A new customer is a tenant created from a blueprint, and onboarding is measured in days with a written checklist someone junior can run. The platform choice either enables this or fights it, which is why multi-tenancy and template support sit near the top of what to check before you commit. On TagoIO, tenant separation and white-label portals are the structure this runs on; the mechanics are the same ones covered in scaling from 10 devices to 1,000, applied across customers instead of within one. Habit 3: let the platform do the watching The ceiling nobody prices in: support and monitoring grow linearly with customers if humans do the watching. At ten customers your team still notices problems by looking. At thirty, either you hire a monitoring team or things get missed until the customer calls, and both outcomes eat the margin that made recurring revenue attractive. The way through is to move first response from people to the platform's intelligence layer. Per-device baselines and anomaly detection catch the drifting sensor before the customer notices. Forecasts turn refills, battery replacements, and capacity problems into scheduled work instead of emergencies. Health checks page you about silent devices instead of relying on someone opening the right dashboard. TagoIO's analytics and AI run this inside the platform, and the output appears in the same UI your customers already use, which quietly changes what they are paying for: not charts, but the fact that problems arrive pre-diagnosed with a recommendation attached. That shift also upgrades your pricing conversation. Monitoring-plus-intelligence tiers justify value-based pricing in a way that dashboard access never will. Habit 4: put boundaries in writing before customer 11 Growth exposes every informal promise. The support expectations that were manageable across ten relationships become unpayable across thirty, so the move is contractual before it is operational: severity levels, response times, exclusions, and maintenance windows in a real SLA, tiered support plans instead of unlimited access to your engineers, and a renewal calendar someone owns. We walked through that shift in moving from one-time projects to recurring services. High-touch customers should be priced as high-touch, not absorbed. The math that says when A useful gate: count the hours your team spends per customer per month on delivery, support, and monitoring. If the number does not fall as customers are added, you are scaling a payroll, not a business. The four habits above exist to bend that curve, and the platform's automation and intelligence layer is what bends it hardest, because it is the only part that gets more valuable per customer without getting more expensive per customer. Past ten customers, the winners look less like project firms and more like small product companies: one packaged solution, one deployment checklist, one intelligence layer watching every tenant, and margins that improve with each logo instead of eroding. The build-or-resell decision you made early either supports that shape or fights it. TagoIO is built for integrators running exactly this model: multi-tenant, white-label, API-first, with analytics and AI in the box. Book a demo or start free. --- ## Open Source vs Managed IoT Platforms: What the Difference Really Costs https://tago.io/blog/open-source-vs-managed-iot-platforms Open source IoT platforms trade license fees for operations: hosting, patching, scaling, and building the analytics layer yourself. What each model really includes, what each really costs, and how to choose honestly. Open source IoT platforms are genuinely good, and that surprises people who expect a sales pitch to say otherwise. ThingsBoard, ChirpStack, and Node-RED are mature, widely deployed, and free to license, and for the right team they are the right choice. But "free to license" and "free to run" are different sentences, and the distance between them is where most open source IoT decisions go wrong. The honest comparison is not license fee versus subscription. It is who operates the platform, who secures it, and who builds the layers the license does not include. What open source actually includes The download gives you the software: device connectivity, data storage, dashboards, and in the stronger projects a rules engine. What it deliberately does not include is the running of it. Hosting, TLS certificates, backups, version upgrades, security patches, scaling the database when the fleet grows, and the 3 a.m. response when ingestion stops: all of it belongs to your team from day one. None of that is hidden. It is the deal. The question is whether your organization wants to be in the platform operations business, because that is a payroll decision, not a licensing one. A realistic self-hosted deployment carries a fraction of an engineer permanently, more during upgrades and incidents, and that cost recurs forever, exactly like the subscription it replaced. What managed actually includes A managed platform sells you the operations you would otherwise staff: uptime backed by an SLA, security patching, certified compliance (TagoIO is ISO 27001 certified), scaling that happens without a migration project, and support with response times. The subscription is the visible cost; the invisible benefit is the engineering roadmap you did not spend on infrastructure. The second difference is less discussed: the application layers above storage. Multi-tenant customer separation, white-label portals, user management with granular permissions, and increasingly the intelligence layer. On TagoIO, analytics and AI are part of the product: forecasting, anomaly detection, and AI-assisted analysis run inside the platform and surface in the same UI as the live data, so a chart carries its forecast band and a drifting sensor gets flagged without anyone building a data science pipeline first. Reproducing that on open source means assembling and maintaining your own stack, model hosting, retraining, and UI integration included. It is doable, and it is a project with headcount attached. Where open source wins Be honest about the cases where self-hosting is right. Full data sovereignty requirements with no acceptable cloud region. Air-gapped or on-premises industrial environments. Teams whose product is the platform itself, where operating it is the differentiation. Heavy customization at the protocol level. Zero-budget experimentation and learning. And any scenario where you already employ the platform team anyway. There is also a hybrid worth knowing: TagoCore is TagoIO's open source edge component, which runs on-premises hardware and forwards to the cloud platform, covering many sovereignty and edge cases without taking on the whole operations burden. Where managed wins Managed wins when the platform is a means rather than the product: when your differentiation is the vertical solution, the hardware, or the customer relationship, and every hour spent on database upgrades is an hour taken from that. It wins on time-to-market, on compliance paperwork someone else has already done, on the analytics layer arriving built, and on the arithmetic that a fraction of a permanent engineer usually costs more than the subscription it would replace. This is the same build-versus-buy logic we ran for AWS IoT Core versus a managed platform, and it lands the same way for most teams: the ones who should self-host already know they should. The three-year comparison Model both options over three years, not one: subscription on one side; hosting, the operations fraction of an engineer, upgrade projects, security reviews, and the analytics build on the other. Include exit costs in both directions, because avoiding lock-in matters with a vendor and with your own accumulated custom code alike. Our three-year pricing guide has the full framework. The decision is rarely about software quality. Open source and managed platforms can both be excellent. The decision is about which business you want to be in: operating infrastructure, or shipping what runs on it. If the second one sounds like you, TagoIO is a managed platform you can evaluate in an afternoon. Book a demo or start free. --- ## How to Scale from a 10-Device IoT Pilot to 1,000 Devices https://tago.io/blog/scale-iot-pilot-to-1000-devices Scaling from a 10-device IoT pilot to 1,000 devices breaks manual onboarding, eyeball monitoring, and hand-tuned dashboards. The four systems to replace them: provisioning, templates, automated intelligence, and fleet health. A 10-device pilot succeeds on effort. Someone registers each device by hand, builds a dashboard with care, watches it daily, and phones the site when a reading looks odd. That effort is exactly why pilots work: attention substitutes for process. But multiply by one hundred and every manual habit becomes arithmetic. Ten minutes of onboarding per device is 167 hours at a thousand. A person who can eyeball ten charts cannot eyeball a thousand. So scaling is not doing the pilot harder; it is replacing four manual habits with four systems before the growth arrives. System 1: provisioning instead of registration At pilot scale, devices are registered through the console, one by one. At fleet scale, onboarding must be an API call or a bulk import: serial number in, configured device out, with its type, tags, and owner assigned automatically. TagoIO's API-first model and connector library exist for this. The target is boring and specific: adding 100 devices should take the same operator time as adding one. While designing it, decide the tagging scheme early (site, customer, hardware revision, firmware version) because every fleet operation you run later, from queries to bulk updates, will lean on those tags. System 2: templates instead of handcrafted dashboards The pilot dashboard was lovingly assembled by hand. Do not build 100 more of them. Define one dashboard blueprint per device type or site type, and instantiate it from the template so improvements roll out everywhere at once. The same discipline applies to alerts and analysis scripts: parameterized, not hardcoded to device IDs. This is the same build-once-apply-everywhere rule that separates profitable managed services from custom shops, and it is the single biggest predictor of whether device 500 costs less to run than device 50. System 3: intelligence instead of eyeballs The third shift is the one most teams underestimate. At 10 devices, a human watching dashboards is the anomaly detection. At 1,000 devices, nobody is watching, and dashboards quietly become the place where problems are discovered late rather than early. The replacement is an analytics layer that watches for you. Baselines that learn normal behavior per device, anomaly detection that flags the sensor drifting away from its history, and forecasts that turn "the tank is at 40 percent" into "the tank runs empty Thursday." TagoIO's built-in analytics and AI run this inside the platform, and the output lands in the same UI as the live data: a forecast band on the chart, a flag on the drifting device, an alert that carries a prediction instead of a threshold breach. Dashboards remain useful at scale, but their job changes from monitoring to investigation. The monitoring belongs to the machine. We covered the techniques in how to detect anomalies in IoT sensor data using AI and forecast-based alerts. System 4: fleet health as its own product At pilot scale, a dead battery is an anecdote. At fleet scale, batteries, connectivity dropouts, and firmware drift are a statistical population that needs its own dashboard: devices silent for more than N hours, battery levels trending toward replacement, gateways carrying degraded traffic, firmware versions in the field. Operations teams that manage 1,000 or more devices treat fleet health as a first-class view, separate from the customer-facing application, and wire alerts to it with the same seriousness as application alerts. What about the platform bill? Scaling 100x also multiplies whatever pricing meter you signed. This is where pricing model predictability stops being theoretical: per-device and tiered models scale linearly and survive the budget meeting; unmetered consumption surprises arrive precisely when the fleet succeeds. Run the 1,000-device bill before the growth, not after. The sequence that works Teams that scale smoothly do it in stages: pilot proves value, then provisioning and templates get built at around 50 devices, then intelligence and fleet health come online before 200, and the growth from there is repetition rather than reinvention. The teams that struggle bolt each system on after its absence caused an incident. The honest test of readiness is a thought experiment: if 100 devices arrived tomorrow, would anything except revenue change? If the answer is a list of manual steps, that list is the roadmap. TagoIO runs ten-device pilots and ten-thousand-device fleets on the same platform, so the systems above are configuration, not migration. Book a demo or start free. --- ## LoRaWAN Network Server vs IoT Application Platform: What Each Actually Does https://tago.io/blog/lorawan-network-server-vs-application-platform A LoRaWAN network server moves packets; an IoT application platform turns them into dashboards, alerts, forecasts, and applications. What each layer does, why you need both, and how they connect. Every LoRaWAN project meets the same confusion in week one. The team stands up a network server, sees device data arriving, and asks why they still need another platform. Or they sign up for an application platform, register a sensor, and ask why nothing shows up. Both questions have the same answer: LoRaWAN deployments run on two distinct layers that are often mistaken for one, and each does a job the other deliberately does not. Getting the split right saves weeks. What follows is what each layer owns, where the boundary sits, and how the two connect in practice. What the network server owns A LoRaWAN network server (LNS) is radio infrastructure management. It authenticates devices when they join, deduplicates the same packet arriving through multiple gateways, schedules downlinks through the best gateway, manages adaptive data rate to preserve battery, and enforces the LoRaWAN MAC layer. ChirpStack, The Things Stack, and carrier-operated servers such as Actility all live here, and we compared the public and private options in private vs public LoRaWAN networks. What the LNS hands you at the end of all that work is a decrypted payload: a few dozen bytes of binary, plus radio metadata. No dashboards, no users, no alerts, no history worth querying. That is not a gap in the product. It is the design. What the application platform owns An IoT application platform starts where the packet stops mattering and the data starts. It decodes the binary payload into named variables, stores them as queryable time series, and turns them into the things people actually buy: dashboards, alerts, user accounts with permissions, reports, and integrations with the rest of the business. The layer that increasingly separates application platforms from each other is intelligence. Storing a temperature reading is table stakes. Forecasting where it will be in six hours, flagging that a sensor started drifting two days before it fails, and converting a prediction into a work order is where the value concentrates. TagoIO runs this in Analysis scripts and built-in analytics and AI, so forecasts, anomaly flags, and recommendations appear inside the same UI as the live data, rather than in a separate BI tool someone has to remember to open. The boundary in one sentence The network server makes sure the packet arrives once, securely, and efficiently. The application platform makes the packet mean something to a human or another system. If a task involves radio, joins, gateways, or spreading factors, it belongs to the LNS. If it involves a user, a chart, a threshold, a forecast, or an ERP, it belongs to the application platform. Confusing the layers costs real time. Teams try to build alerting inside an LNS with webhooks and scripts, and end up maintaining a fragile application platform they never intended to write. Or they expect an application platform to diagnose gateway coverage, which it cannot see. Each layer is deliberately blind to the other's job. How the two connect In practice the integration is a data bridge. The LNS pushes every decoded uplink to the application platform over HTTPS or MQTT, and downlinks flow back the same way. TagoIO ships pre-built integrations for the major network servers, including The Things Network, ChirpStack, and carrier networks, plus a connector library of hundreds of sensors, so payload decoding is configuration rather than code. A typical production stack ends up as: sensors, gateways, an LNS (public network or private ChirpStack), and TagoIO on top for everything a customer sees. The LNS choice and the platform choice are independent decisions, which is healthy: you can switch network operators without rebuilding your application, and vice versa. Do you ever need only one? Sometimes. A pure coverage study can live on an LNS alone. A cellular or Wi-Fi deployment skips the LNS entirely and speaks directly to the application platform. But if the project involves LoRaWAN sensors and anyone other than an engineer looking at the data, you need both layers, and the honest budget line includes both from the start. If you have an LNS running and want to see the application layer working against it, TagoIO connects in minutes. Book a demo or start free. --- ## How IoT Platform Pricing Models Differ, and Which Is Most Predictable https://tago.io/blog/iot-platform-pricing-models-compared Per-device, consumption, tiered, and flat IoT platform pricing models compared on one axis: how predictable the bill is at 10x the devices. Which model fits which deployment, and the questions that expose surprises. Every IoT platform prices differently, and every pricing page looks reasonable at pilot size. But the bill that matters is not the pilot bill. It is the invoice that arrives after the fleet grows tenfold, the message frequency doubles because a customer wanted faster updates, and the data retention policy quietly became a compliance requirement. Two platforms that cost the same at 50 devices can differ by a factor of five at 5,000, purely because of how the meter is built. So the right way to compare pricing models is not "which is cheapest today" but "which can I predict well enough to put in a three-year budget." Four models cover almost everything on the market. Each one optimizes for something different, and each one surprises you somewhere. Per-device pricing: predictable by design A fixed price per connected device per month. Multiply devices by rate and you have the bill, which makes it the easiest model to defend in a budget meeting and the easiest to pass through to your own customers if you resell. The surprise hides in the definition of "device." Some vendors count anything with an ID, including virtual devices, gateways, and integrations. Others tier the device price by message volume, which quietly turns per-device into consumption pricing. Read the definition before you model anything. Consumption pricing: pay for what you use, predict what you cannot Metering on messages, data points, storage, or compute. Cloud infrastructure made this model standard, and hyperscaler IoT services like AWS IoT Core price this way. It is genuinely cheap at low volume and it scales smoothly, with no step changes. The problem is that consumption is a property of your application's behavior, not your contract. A firmware change that doubles reporting frequency doubles the bill. A chatty device model, a debugging period, a customer that wants one-minute updates: all of it lands on the invoice. Consumption works when you control the data pipeline tightly and can enforce reporting discipline. It punishes teams that cannot. Tiered plans: predictable until the cliff Fixed monthly fee covering a bundle: so many devices, so much data, so many users. Inside the tier, perfectly predictable. The surprise is the cliff at the boundary, where device 1,001 forces the jump to a plan sized for 5,000 and the unit economics lurch. Map the tier boundaries against your realistic growth curve before signing, and check what happens to historical data if you ever need to step down a tier. Flat and seat-based pricing: simple, until usage is the product A flat platform fee, sometimes with charges per user seat. Simple to budget and generous at high device counts. But vendors cannot sustain flat pricing against unbounded usage, so the limits reappear in fair-use clauses and throttling policies. Flat pricing is honest only when the ceiling is written down. The predictability test Whatever the model, three questions expose most surprises before the contract does. First, what happens to my bill if devices grow 10x? If the answer requires a spreadsheet with more than one variable, budget risk lives in that spreadsheet. Second, what happens if message frequency doubles with the same device count? That isolates the consumption exposure. Third, which line items are metered that I do not directly control? Storage retention, API calls made by integrations, and alert volume are the usual hidden meters. Predictability also has a second-order benefit: it is what lets you price your own managed service with confidence, because you cannot sell a fixed monthly fee downstream while carrying an unbounded meter upstream. Which model wins For most mid-market deployments and nearly all resellers, per-device or tiered pricing wins, not because the total is always lower but because the variance is. Consumption pricing wins for lean, well-instrumented teams with strict control over reporting behavior. Flat pricing wins when the vendor writes the ceiling into the contract. TagoIO publishes its rates on the pricing page, and the fastest way to sanity-check any platform's model is to run your realistic year-three fleet through it, not your pilot. For the full cost picture beyond the platform fee, including integration and operations, see comparing IoT platform pricing over a three-year horizon. And if you are still assembling the shortlist, start with the IoT platform buyer's guide. Ready to model your own numbers? Book a demo or start free. --- ## The Biggest Mistakes System Integrators Make When Building on IoT Platforms https://tago.io/blog/biggest-mistakes-system-integrators-iot-platforms The most expensive mistakes system integrators make when building on IoT platforms: rebuilding what the platform ships, underpricing support, shipping dashboards without intelligence, and skipping multi-tenancy. System integrators pick up an IoT platform to move faster, and most of the time it works: connectivity, storage, dashboards, and user management arrive on day one instead of month nine. But speed hides a trap. The same platform that lets you ship a first project in weeks also lets you ship structural mistakes in weeks, and those mistakes compound quietly across every customer you add. The integrators who stall at three or four accounts almost always made one of the errors below early, priced it into nothing, and paid for it monthly. The six below show up most often, along with what the profitable firms do instead. Mistake 1: rebuilding what the platform already ships The most expensive habit is treating the platform as a message broker and rebuilding everything above it: custom portals, custom alerting, custom user management. Every custom layer is code you maintain for the life of the contract, and it turns a product margin into a payroll cost. Before writing anything, inventory what the platform provides. On TagoIO that includes dashboards, alerts, user and permission management, a device connector library, and a white-label portal layer in TagoRUN. The rule that protects margin: build only what differentiates you, configure everything else. Our guide on build or resell runs the full economics. Mistake 2: shipping dashboards and calling it a solution A dashboard shows what already happened. For the customer, that is homework: someone has to open it, notice the drift, interpret it, and react. Integrators who stop at charts end up competing on chart aesthetics, which is a race to the bottom. The differentiation now sits one layer up, in intelligence. Forecasting when a tank runs empty, flagging the sensor that started drifting before it fails, turning a prediction into a work order. TagoIO's Analysis scripts and built-in analytics and AI run this logic inside the platform, so a forecast band, an anomaly flag, or a recommendation card lands in the same UI the customer already uses. The customer stops paying you for a picture of their data and starts paying you for decisions they did not have to make. Mistake 3: one account, many customers Putting several customers inside a single account with naming conventions instead of real separation feels efficient at two customers and becomes a liability at five: no per-customer permissions, no per-customer billing, and an offboarding that requires surgery. Multi-tenancy is a day-one decision. Each customer gets their own tenant space, their own users, their own data boundary, and the integrator operates above all of them. That is exactly the structure white-label IoT formalizes, and retrofitting it later costs more than any other correction on this list. Mistake 4: underpricing support to win the deal Support is the cost that grows with success. Every deployed device is a future ticket, and a handful of high-touch customers can erase the profit from a dozen quiet ones. Integrators who fold support into a thin monthly fee discover this in year two. Price support as its own line with severity levels and response times, put the boundaries in writing, and align the whole document with your platform vendor's commitments. We covered the mechanics in moving from projects to recurring services and how to price an IoT managed service. Mistake 5: hardcoding one customer's solution The first project always works. The mistake is building it so specifically (hardcoded device IDs, one-off scripts, bespoke dashboards) that customer two starts from zero. The firms that scale treat the first deployment as a template: parameterized analysis scripts, dashboard blueprints, a documented onboarding path. Build once, apply everywhere. That single discipline is what separates a project shop from a product business, and it is what makes the managed service model profitable. Mistake 6: ignoring exit costs until exit Data export, device migration paths, and contract ownership rarely get read before signing. Then a customer asks to leave, or you need to switch vendors, and the answer decides whether you keep your reputation. Check for documented export APIs in standard formats and read the fine print on who owns the customer relationship. Our vendor lock-in guide lists the questions worth asking while you can still negotiate. The pattern behind all six Every mistake here is the same mistake wearing different clothes: optimizing for the first deal instead of the tenth. The platform choice, the tenant structure, the pricing, the intelligence layer, all of it looks fine at one customer and decides your margin at ten. If you are evaluating platforms with the tenth customer in mind, start with the buyer's guide, then look at how TagoIO handles multi-tenancy, white-label, and built-in analytics and AI. Book a demo or start free. --- ## What Is Predictive Analytics for IoT, and How Do You Get Started? https://tago.io/blog/what-is-predictive-analytics-for-iot A plain guide to predictive analytics for IoT: what it means, where it pays off, the honest requirements, and a first project you can ship on TagoIO. Predictive analytics is one of those phrases that shows up in every IoT pitch and rarely gets defined. It sounds like a product you buy or a team you hire. In practice it is something narrower and more useful: using the data you already collect to say something specific about what happens next, so a decision can be made with lead time instead of hindsight. Most IoT platforms are very good at descriptive analytics, showing what happened and what is happening. That is where value stalls for a lot of deployments. The dashboards are live, the alerts fire, and the operation still runs reactively because nothing on the screen looks forward. Predictive analytics is the step that closes that gap, and getting started matters more than getting it perfect. This is a plain guide to what it is and how to ship your first one. The three kinds of analytics, briefly It helps to place predictive analytics against its neighbors. Descriptive analytics tells you what happened: yesterday's peak, this shift's average. Predictive analytics tells you what is likely to happen: the load this afternoon, the runout date, the component trending toward failure. Prescriptive analytics goes one step further and recommends or takes an action: shed this load, order this part now. Most teams have descriptive analytics already. Predictive is the achievable next step, and it is the one that changes how the operation runs, because a forecast is what lets you act before a problem instead of after. Where it pays off in IoT Predictive analytics earns its cost wherever acting early beats acting late, and IoT is full of those. Predictive maintenance spots a machine trending toward failure so you service it on a schedule instead of after a breakdown. Demand and consumption forecasting positions stock and plans production ahead of need. Depletion forecasting triggers refills before a tank runs dry. Energy forecasting avoids the peak that sets a demand charge. Predictive alerting warns of a threshold breach while there is still time to prevent it. The common thread is lead time. If knowing something a few hours or days ahead would change what you do, that is a candidate for predictive analytics. If it would not change anything, skip it, because a forecast nobody acts on is a chart, not a capability. The honest requirements Predictive analytics has real prerequisites, and pretending otherwise is why projects disappoint. You need history that covers the pattern you want to predict, weeks for a daily cycle, longer for seasonal ones. You need data that is reasonably clean and consistent, because a model trained on gaps and glitches learns gaps and glitches. You need a decision the forecast will actually feed, named before you build. And you need to score the forecast continuously, because an unmeasured model quietly rots and takes your trust with it. None of these require a data science org. They require picking a signal with enough history, a decision worth informing, and the discipline to measure whether the forecast is any good. Where teams go wrong The usual mistakes are predictable. Starting with the most advanced model instead of the simplest one that works, and losing a quarter to it. Building a forecast with no decision attached, so it becomes a dashboard nobody uses. Shipping a model and never scoring it, so it degrades unnoticed. And trying to predict everything at once instead of proving the loop on one signal. Avoiding these is most of the battle. Your first predictive project Start small and concrete. Pick one signal where seeing a few hours or days ahead would change a real decision, a tank that must not run dry, a peak that costs money, a machine whose failure is expensive. Build the simplest forecast that could work, often a seasonal baseline, in a scheduled script that reads recent data and writes a prediction back. Plot it against actuals so you can see how it does. Score the error on a schedule. Then wire the prediction to the one decision, an alert, a reorder, a work order. That single loop, running live and measured, teaches you more than any planning, and it is the template every later predictive project reuses. Because TagoIO Analytics produces forecasts against your live data, the whole loop, read, forecast, score, act, lives on the platform you already use. Predictive analytics for IoT is not a product you switch on. It is a habit you start with one signal, and see how TagoIO Analytics runs it. You can start without writing any code. Sign in to TagoIO Analytics at sight.tago.io/login with your TagoIO account, pick one signal, and train a model in minutes. It gives you forecasts and anomaly detection on your own data, so you do not need to be a data scientist to get real results. --- ## How to Turn IoT Data into a Demand Forecast https://tago.io/blog/turn-iot-data-into-demand-forecast IoT data measures real consumption, which makes it a strong base for demand forecasting. How to build one and act on it with TagoIO. Most demand forecasts are built on sales history. That tells you what you shipped, which is a decent proxy for demand until you look closely. Sales data hides the demand you failed to meet, the customer who found the shelf empty and went elsewhere, and it lags reality by however long it takes to close the books. IoT changes the input. A connected dispenser, a monitored bin, a metered line, and a tracked asset all measure consumption as it happens, at the point where it happens. That is closer to true demand than an invoice, and it arrives in real time instead of at month end. The catch is that raw consumption readings are not a forecast, they are the raw material for one, and turning the stream into a number the business can plan against takes a few deliberate steps. Here is the path. Why IoT data is a better base for demand Sales figures answer "what did we sell." Consumption data answers "what did people actually use," and the gap between those two is exactly the information a demand forecast needs. A vending machine that reports stock levels shows demand even for the item that sold out at noon and stopped generating sales for the rest of the day. A monitored tank at a customer site shows their real usage rate, not just the timing of their orders. Because the signal is measured at the source and in real time, it also updates far faster than a sales-driven forecast. You see a demand shift as consumption moves, not weeks later when the reorder pattern finally reflects it. For anything that turns over quickly, that speed is the advantage. Step one: turn readings into a demand series Raw IoT data is not demand yet. A level sensor reports how full a tank is; demand is how fast it empties. So the first step is deriving a consumption series from the state series: differencing levels into a usage rate, counting dispense events, or summing metered flow per period. This is a simple transform in a TagoIO Analysis that reads the raw variable and writes a clean per-hour or per-day consumption variable. Get this layer right, because everything downstream forecasts the derived series, not the raw readings. Handle the obvious traps here too: a refill looks like negative consumption and has to be filtered, and a sensor gap should not read as zero demand. Step two: forecast the demand series With a clean consumption series, this is ordinary time-series forecasting. Demand usually carries strong seasonality, time of day, day of week, and often a yearly pattern, so a seasonal model is the right starting point, and the same progression applies as any IoT forecast: seasonal baseline first, machine learning only when a signal depends on several drivers and the simpler model has measurably failed. Demand forecasts especially benefit from external drivers. Weather moves consumption of many products. Promotions, holidays, and local events move it sharply. Where you have that data, feed it in, because a demand spike around a known event is predictable only if the model knows the event is coming. Step three: forecast per unit, then aggregate A single blended demand number hides the detail operations needs. The stronger pattern is to forecast at the unit level, per machine, per site, per SKU, using tags to run one script across the whole fleet, and then aggregate. That gives you both the total for planning and the breakdown for action: which sites are trending up, which product is about to run short where. Aggregating unit-level forecasts also tends to be more accurate than forecasting the blended total directly, because each unit's pattern is cleaner than the noisy sum, and it lets you route each local signal to the person who acts on it. From forecast to decision A demand forecast earns its cost when it drives stocking, production, and distribution. Replenishment: send stock to the machine or site the forecast says will run short, before it does. Production planning: schedule output against predicted demand rather than last month's sales. Distribution: position inventory where demand is trending, not where it was. On TagoIO the loop is familiar. Devices report consumption, a scheduled Analysis derives the demand series and forecasts it per unit, and predictions are written back as variables that feed dashboards, alerts, and downstream systems through the API. With TagoIO Analytics, the weather-and-event-aware demand forecast lives next to the consumption data. Start with one product and one decision Pick a product where stockouts or overstock cost you, derive its consumption series, forecast it per unit, and wire the forecast to one decision, replenishment is usually the fastest to show value. Prove it on one product line, then scale the same tag-based approach across the catalog. IoT gives you demand measured at the source in real time. See how TagoIO Analytics turns that stream into a forecast the business can plan against. TagoIO Analytics can build the demand model for you with no code. Sign in at sight.tago.io/login with your TagoIO account and train a forecast on your consumption data in minutes, anomaly detection included, without a data scientist. --- ## How to Forecast Tank and Silo Levels Before They Run Out https://tago.io/blog/forecast-tank-silo-levels-before-they-run-out Level sensors tell you what's left. Forecasting tells you when it runs out. How to predict tank and silo depletion and trigger refills with lead time on TagoIO. A level sensor on a tank or silo answers one question well: how much is left. You open the dashboard, you see 40 percent, and you move on. For a while that is all you need, because someone remembers to check and someone remembers to reorder. The failure shows up at scale. When you are monitoring one tank, a human can eyeball the trend. When you are monitoring hundreds across sites, nobody can, and the reading that matters is not the level, it is the date. Forty percent is comfortable if the tank drains slowly and a refill takes a day. Forty percent is a crisis if it drains fast and the supplier needs a week. The number on the dashboard does not tell you which, and a stockout, or an emergency delivery at a premium, is what happens when you guess wrong. Forecasting turns the level into a runout date. The signal is easy, which is the good news Depletion is one of the more forecastable IoT signals, because most tanks and silos drain with a consistent pattern. A fuel tank feeding a steady process, a water reservoir on a daily draw, a feed bin on a herd's routine: consumption tends to repeat, so a model has clear structure to learn from. For a steady drain, even a moving-average rate of depletion projected forward gives a usable runout date. Where consumption follows a cycle, higher use on weekdays, seasonal demand, a seasonal model captures it. You rarely need heavy machine learning to predict a level, which means this is one of the fastest forecasts to get into production. What to predict: the date, not the level The useful output is not "predicted level next Tuesday." It is "days until this tank reaches the reorder point." That framing matters because it maps directly to the decision. Set the reorder point at the level that leaves enough buffer for your real lead time, then forecast when the tank will hit it. Get the lead time right and the reorder point almost sets itself. If a refill takes three days door to door, the reorder point is the level three days of typical consumption above empty, plus a safety margin for a bad week. The forecast then tells you the date you cross it, which is the date you place the order. The drivers that change the drain rate A pure "current rate continues" forecast is fine until the rate changes, and for tanks and silos the rate usually changes for knowable reasons. Production schedule drives industrial consumption. Weather drives heating fuel and irrigation water. Herd size and feed schedule drive an agricultural silo. A forecast that ignores these will be confident and wrong right when demand shifts. Where a driver is available as data, feed it into the model. A TagoIO Analysis can pull a weather forecast for a heating-oil tank, or read a production schedule, and adjust the predicted drain rate accordingly. When drivers are not available, lean on the seasonal pattern and widen the safety margin to cover the uncertainty. From forecast to refill The point of the runout date is to trigger action without a human watching every tank. The loop: a scheduled Analysis reads each tank's recent level history, estimates the drain rate, projects the runout and reorder-point dates, and writes them back as variables per device, selected by tags so the same script runs the whole fleet. An alert fires when a tank's forecast reorder date falls inside the ordering window, routed to whoever places the order, by email, SMS, or a webhook into a procurement system. That turns replenishment from "someone remembered to check" into "the system flags the tank that needs ordering, with enough notice to order normally instead of in a panic." Across a fleet, that is the difference between routine logistics and recurring emergencies. Start with your worst stockout Pick the tank or product where running dry hurts most, or where you have paid for an emergency delivery. Build the drain-rate forecast for it, set the reorder point from your true lead time, and wire the alert to the person who orders. Prove it on one, then roll the same tag-based script across the fleet. A silo monitoring setup that predicts depletion instead of just reporting it is a common first predictive win, because the signal is easy and the payoff is concrete. See how TagoIO Analytics runs the depletion forecast and drives the refill alert. If you would rather not script the drain-rate model, TagoIO Analytics forecasts depletion for you. Sign in at sight.tago.io/login with your TagoIO account and train a model on your level data in minutes, with forecasts and anomaly detection, and no data scientist required. --- ## From Reactive to Predictive: Building Forecast-Based Alerts for IoT https://tago.io/blog/forecast-based-alerts-iot Threshold alerts fire after the problem starts. Forecast-based alerts fire before. How to build predictive alerting on IoT data with TagoIO. The first alert every IoT project builds is a threshold: tell me when the temperature goes above 8 degrees, when the tank drops below 10 percent, when the pressure crosses a limit. It is the right place to start, and it works. When the value crosses the line, someone gets a message. The limitation is baked into the design. A threshold alert fires when the problem has already started. By the time the freezer reads 8 degrees, the product is already warming. By the time the tank hits 10 percent, you have hours, maybe, to arrange a refill that needs a day of notice. Reactive alerts tell you about a problem at the worst possible moment: once it is real. Forecast-based alerts move that message earlier, to while there is still time to prevent it. What a predictive alert actually is A predictive alert does not watch the current value. It watches the forecast of the value. Instead of "temperature is above 8 now," it fires on "temperature is trending to cross 8 within two hours." The trigger is the same threshold, applied to the predicted signal rather than the live one. That one shift changes the character of the alert. It stops being a record of failure and becomes a window to act. The size of that window is the lead time your forecast provides, and it is the entire value of the approach: enough warning to dispatch a technician, order a refill, shift a load, or cool a space before the limit is breached instead of after. The two ingredients Building this needs a forecast and an alert rule pointed at it. The forecast is a scheduled script that reads recent data and writes a predicted value and a horizon back as variables, the same forecasting loop that powers a dashboard projection. On TagoIO that is an Analysis producing, say, a "predicted temperature in 2 hours" variable for each device. The alert is an ordinary rule, except it targets the predicted variable instead of the raw reading. "Notify when predicted-temperature-2h exceeds 8." Because the prediction is stored like any other variable, the platform's normal alerting treats it as a first-class signal. You are reusing the alerting you already have, aimed at the future. Handle the honest problems Predictive alerting has two failure modes worth designing for from the start. False alarms. A forecast is not certain, so a predictive alert can fire for a problem that never arrives. Too many of those and operators mute it, which is worse than no alert. The defenses: only fire when the forecast crosses the threshold with reasonable confidence, and require the predicted breach to persist across a couple of forecast runs rather than a single noisy spike. Tune the balance toward the cost of a miss versus the cost of a false alarm for that specific signal. Silent model drift. If the underlying forecast quietly degrades, your predictive alerts degrade with it, and nobody notices until a breach arrives with no warning. This is why the forecast has to be scored continuously. When prediction error climbs past tolerance, that itself should raise an alert to a human, because a predictive alerting system with a stale model is worse than a threshold, since people have stopped watching the raw value. Keep the threshold too Predictive alerting does not replace the reactive threshold, it layers on top. The forecast alert gives you lead time on the expected path. The plain threshold stays as the backstop for the case the forecast never saw coming, the sudden failure no trend predicted. Run both: predictive for warning, reactive as the safety net. Building it on TagoIO The pieces are already on the platform. A scheduled Analysis in Node.js or Python produces the forecast variable. A standard alert rule watches that variable and notifies by email, SMS, webhook, or into your dashboards. A second scoring Analysis guards the model. Nothing here is a special system, it is the forecasting loop plus the alerting you already run, wired together. Start by taking your most valuable existing threshold alert and adding a predictive twin that watches the forecast of the same signal. Keep the original as the backstop, tune the confidence until operators trust it, and you have turned an after-the-fact notification into time to act. See how TagoIO Analytics runs the forecast behind a predictive alert. To get the forecast behind a predictive alert without writing one, use TagoIO Analytics. Sign in at sight.tago.io/login with your TagoIO account and train a model on your data in minutes to get forecasts and anomaly detection you can wire an alert to, without a data scientist. --- ## How to Forecast Energy Consumption with IoT Data https://tago.io/blog/how-to-forecast-energy-consumption-iot A practical approach to forecasting energy consumption from IoT meter data: the seasonality that dominates load, the drivers to add, and how to run it on TagoIO. Sub-metering a building or a site gives you a clear picture of what you used. You can see yesterday's peak, last month's total, which floor draws the most. That visibility already pays for itself in spotting waste and validating bills. The trouble is that energy decisions are about tomorrow, not yesterday. Demand charges are set by the single highest peak in a billing period. Battery dispatch, load shifting, and buying energy ahead all depend on knowing the load before it arrives. A meter that only reports the past leaves the money on the table, because the actions that cut cost have to happen before the peak, not after you see it on a chart. Forecasting is how you get ahead of it. Energy load is one of the friendliest signals to forecast Good news first: electrical load is one of the more predictable IoT signals, because it is driven by human and seasonal rhythms that repeat. A commercial building follows a daily curve, low overnight, ramping in the morning, peaking in the afternoon, and a weekly one, weekdays unlike weekends. Layer in a yearly cycle from heating and cooling and you have a signal with strong, stable structure. That structure means you do not need exotic modeling to get a useful forecast. A seasonal model that captures hour-of-day and day-of-week patterns will get you most of the way for a typical building. This is the same seasonal-baseline approach that works across IoT monitoring, and energy is where it shines, because the cycles are so consistent. The driver that breaks a pure calendar model: weather A calendar-only forecast assumes every Tuesday in July looks the same. Then a heat wave arrives and cooling load blows past the prediction, exactly on the day the forecast mattered most for a demand charge. Temperature is the dominant external driver of energy load in most buildings, so a serious forecast has to include it. In practice that means pulling a local weather forecast into your model as an input alongside the calendar features. Because a TagoIO Analysis can call an external weather API, you can feed tomorrow's forecast temperature into today's load prediction. Adding weather is usually the single biggest accuracy gain over a calendar-only baseline for energy signals. Other useful drivers, depending on the site: occupancy, production schedule, and known events like a shift change or a planned shutdown. Each is another input the model can learn from. From forecast to money A load forecast is only worth building if it drives an action. The common ones: Peak avoidance. If the forecast says you will hit a new monthly peak this afternoon, you can shed non-critical load or dispatch a battery before the peak sets your demand charge for the whole period. This is often the largest single saving from an energy forecast. Procurement and shifting. Knowing tomorrow's load profile lets you buy energy or shift flexible loads into cheaper windows. Budgeting and anomaly context. A month-ahead consumption forecast gives finance a number to plan against, and it doubles as context for anomaly detection: consumption far above forecast is a signal something is wrong, a stuck damper, a failed control, a leak. Building it on TagoIO The loop fits the platform directly. Meter data lands on TagoIO. A scheduled Analysis reads the recent load history for a meter or a group selected by tags, pulls a weather forecast, runs a seasonal or machine learning model, and writes the predicted load back as a variable. A dashboard plots forecast against actual, and an alert fires when the forecast projects a new peak with enough lead time to act. Because TagoIO Analytics produces the load forecast beside your meter data, the weather-informed model lives in one place, not in a separate system you have to sync. Start with peak, add weather, then act Begin with a seasonal forecast of the metric that costs you the most, usually peak demand, and plot it against actuals so you can see how it does. Add weather as an input, because for energy it is almost always the biggest single improvement. Then wire the forecast to one action, peak shedding or battery dispatch, and let it start paying for itself. See how TagoIO Analytics runs the weather-informed model behind an energy forecast. The no-code path is TagoIO Analytics, which forecasts energy load for you. Sign in at sight.tago.io/login with your TagoIO account and train a model on your meter data in minutes, with forecasts and anomaly detection, and no data scientist required. ---