Skip to main content
SyncVeloSyncVelo

SyncVelo IoT OS

One operating system for every connected device

IoT OS is being built to develop, connect, deploy and operate devices of every kind, from sensors and controllers to gateways and edge boxes, with AI alongside. Devices already connect over MQTT 5 or HTTP, each described by a device type; their telemetry shows in IoT OS's own console and on its dashboards, and their alarms raise alerts by email, SMS, WhatsApp and push.

  • Its own console, available today
  • MQTT 5 and HTTP ingest, available now
  • On the SyncVelo platform you already use
Talk to an expertSign in
AvailableIllustration: devices of every kind streaming in over MQTT and HTTP, with sample readings.

AvailableAvailable today

IoT OS runs on the shared SyncVelo platform, which is in service today.

  • Its own consoleIoT OS opens at its own address, with its own sign-in page.
  • One SyncVelo accountOne sign-in takes you between the SyncVelo consoles.
  • The marketplaceOrganizations add IoT OS to their plan, where it is launched.
  • Launched by countryHQ switches IoT OS on, closed or off, country by country.
AvailableIO1.1

Device types

Describe a kind of device once, then connect every one like it

A device type is the template for a kind of device: the telemetry it sends, the attributes it keeps, the commands it accepts and the alarms it can raise. Every device of that type inherits it, so its data arrives already understood.

  • Telemetry fields with their type, unit and valid range
  • Attributes such as model, site and firmware version
  • Commands declared with the type; sending them comes with IO2
  • Alarms with a condition and a severity
AvailableIllustration of the device-type editor, with a sample type.
AvailableIO1.1

Connectivity

MQTT 5 over TLS, with a private topic space for each organization

Devices connect over MQTT 5 with TLS, each with credentials of its own, or post their readings over HTTP. Every organization has a topic space of its own, kept apart from every other organization's.

  • MQTT 5 over TLS for devices that stay connected
  • Credentials for each device, so each one has its own identity
  • A topic space per organization
  • HTTP ingest for devices and systems that simply post readings
AvailableIllustration of MQTT topics per organization. Topic names are illustrative.
AvailableIO1.1–IO1.2

Telemetry and alarms

Every reading, live, charted and checked

Each device has a page with the latest value of every field, its history and charts, and its alarms, active and past. Every reading is checked against the device type, and refused readings are counted and shown. Each time an alarm starts holding, it raises an alert through SyncVelo's notification engine, the one that sends Fleet's alerts: email, SMS, WhatsApp and push, under your organization's notification policies.

  • Latest values, with the time each one arrived
  • History and charts for each device
  • Alarms, active and past, that raise alerts by email, SMS, WhatsApp and push
  • Readings checked against the device type, with refused ones counted
AvailableIllustration of a device page with sample readings, and an alarm that raises alerts.

How it works

From a new device type to devices in service

How onboarding works, step by step, with the status of each step.

  1. 1
    AvailableIO1.1

    Create a device type

    Declare its telemetry, attributes, commands and alarms.

  2. 2
    AvailableIO1.1

    Give each device credentials

    One identity per device, in your organization's topic space.

  3. 3
    AvailableIO1.1

    Connect

    Over MQTT 5 with TLS, or HTTP, with ready samples. Open SDKs follow in IO4.

  4. 4
    AvailableIO1.1

    See the first message

    Latest values, history and charts on the device's page.

  5. 5
    AvailableIO1.2

    Watch with alarms

    Alarms raise alerts by email, SMS, WhatsApp or push.

  6. 6
    RoadmapIO2–IO3

    Command and update

    Twins, approved commands and firmware released in rings.

RoadmapIO2

Twins and commands

Set what a device should be. See what it is.

A device twin will hold two states: the one you want and the one the device reports, with the difference in plain view until they match. Commands will need permission, and those that can cause harm will need a named person's approval and a safe-state check, with every step in the audit trail.

  • Desired and reported state side by side
  • Commands limited by roles and permissions
  • Named approval for commands that can cause harm
  • Safe-state checks and a full audit trail
RoadmapPreview of device twins and commands, planned for IO2.
RoadmapIO3

Firmware over the air

Signed firmware, released in rings, with rollback built in

Firmware will ship as signed images, released to a small ring of devices first and then to wider ones. A device that cannot start a new image will go back to the version that worked, on its own, so a bad release stays small.

  • Signed images: devices install only firmware with a valid signature
  • Staged rollouts, from a small first ring to everyone
  • Automatic rollback to the last version that worked
  • For microcontrollers, and for Linux gateways and edge boxes
RoadmapPreview of staged firmware rollouts, planned for IO3.
RoadmapIO4–IO5

Gateways, networks and edge AI

Fieldbus, radio and constrained devices, all speaking one language

Machines on Modbus, OPC UA or BLE will connect through edge gateways that turn their data into device telemetry. LoRaWAN, CoAP and LwM2M will bring in battery-powered and constrained devices. Edge boxes will run AI models deployed and managed from IoT OS.

  • Modbus, OPC UA and BLE through edge gateways (IO5)
  • LoRaWAN through a network server, CoAP and LwM2M (IO4)
  • Edge AI, with models managed from the console (IO5)
  • Vision AI's edge boxes managed as IoT OS devices
RoadmapPreview of edge gateways and edge AI (IO5), and of LoRaWAN, CoAP and LwM2M (IO4).
RoadmapIO4

For device makers

Open SDKs, a simulator and a first message in five minutes

Device SDKs under an open licence will let makers build SyncVelo into their own firmware and products. A device simulator and guided onboarding will take a team from nothing to its first message in minutes, with keys and certificates managed in the console.

Planned SDKs

  • C · ESP-IDF
  • C · Zephyr
  • C · FreeRTOS
  • Arduino
  • MicroPython
  • Python
  • Node
device-sdk · previewRoadmap
1// Preview of the planned SyncVelo device SDK (IO4), not released2#include "syncvelo/device.h"3 4void app_main(void)5{6    sv_device_t *dev = sv_connect(&(sv_options_t){7        .device_type = "cold-room-sensor",8        .credential  = SV_CREDENTIAL_FROM_NVS,9    });10 11    sv_publish_float(dev, "temperature", read_temperature());12}

Preview of the planned interface. The device SDKs are on the roadmap (IO4) and not released yet; names and calls may change.

  • RoadmapIO1–IO4

    Device simulator

    Virtual devices that send data before any hardware exists.

  • RoadmapIO1–IO4

    First message in five minutes

    Guided onboarding, with a code snippet for each SDK.

  • RoadmapIO1–IO4

    Keys and certificates

    Device keys and certificates managed in the console.

Trust and security

Built on a platform that already runs

IoT OS runs on the shared SyncVelo platform, in service today. Device security arrives with each delivery, and each item below says where it stands.

Available

From the SyncVelo platform, today

  • Organizations in a reseller tree
  • Roles and permissions
  • White label and custom domains
  • REST API, SDK and signed webhooks
  • Notifications by email, SMS, WhatsApp and push
  • Reports and KPI dashboards, with CSV, XLSX and PDF downloads
  • Audit trail
  • HQ switches each product on, country by country
AvailableRoadmap

For devices, as each delivery lands

  • TLS on every MQTT connection · Available IO1.1
  • Credentials for each device · Available IO1.1
  • A topic space per organization · Available IO1.1
  • Named approval and safe-state checks for commands that can cause harm · Roadmap IO2
  • Signed firmware images · Roadmap IO3
  • Keys and certificates managed in the console · Roadmap IO1–IO4
  1. RoadmapIO4–IO5SDKs, networks and the edgeOpen device SDKs, LoRaWAN, CoAP and LwM2M, gateways, edge AI
  2. RoadmapIO2–IO3Twins, commands and firmwareDesired and reported state, approved commands, signed rollouts
  3. AvailableIO1.1–IO1.2Device types and telemetryMQTT 5 and HTTP ingest, history, charts, alarms and alerts
  4. AvailablePF1The IoT OS consoleIts own address, sign-in page and marketplace
  5. AvailableThe SyncVelo platformOrganizations, roles, API, webhooks, notifications, reports and dashboards, audit, HQ

Every feature

The full IoT OS catalogue

Every feature planned for IoT OS, each with its status from the product plan. Filter by what you can use today.

Available
Available
Built and in service today.
Next
Next
Being built now, or straight after.
Roadmap
Roadmap
Designed and scheduled; not built yet.

Console and account

  • Available

    Its own console

    IoT OS opens at its own address, with its own sign-in page and menus, on the SyncVelo account.

  • Available

    One sign-in

    Move between the SyncVelo consoles without signing in again, with one account and one MFA set-up.

  • Available

    The marketplace

    Organizations add IoT OS to their plan from the marketplace in any SyncVelo console, where it is launched.

  • Available

    Launch by country

    HQ launches, closes or switches IoT OS off by country, sub-region or region, and every change is audited.

The SyncVelo platform

  • Available

    Organizations in a reseller tree

    Partners, resellers and their customers, managed as one tree of organizations.

  • Available

    Roles and permissions

    What each person may see and do, organization by organization.

  • Available

    White label and custom domains

    A partner's own brand and domain on the platform; custom domains open Fleet's console today.

  • Available

    REST API, SDK and signed webhooks

    The platform's API with an SDK, and webhooks signed so that receivers can verify them.

  • Available

    Notifications

    Email, SMS, WhatsApp and browser push, routed by country.

  • Available

    Audit trail

    Changes recorded with who made them and when.

Device types and connectivity

  • Available

    Device types

    Templates declaring telemetry fields, attributes, commands and alarms.

  • Available

    MQTT 5 over TLS

    Devices connect over MQTT 5, encrypted with TLS.

  • Available

    Credentials for each device

    Every device has credentials of its own.

  • Available

    A topic space per organization

    Each organization's topics are kept apart from every other organization's.

  • Available

    HTTP ingest

    Devices and systems can post their readings over HTTP.

Telemetry, alarms and alerts

  • Available

    Latest values

    The last reading of every field, on each device's page.

  • Available

    History and charts

    Each device's readings over time, with charts.

  • Available

    Alarms and alerts

    An alarm on a reading's value raises an alert each time it starts holding, sent by email, SMS, WhatsApp and push through the notification engine, and acknowledged and closed in the console.

Twins and commands

  • Roadmap

    Device twins

    Desired and reported state side by side, with the difference shown.

  • Roadmap

    Commands with permissions

    Only the roles allowed to send a command will be able to send it.

  • Roadmap

    Named approval

    Commands that can cause harm will need a named person's approval.

  • Roadmap

    Safe-state checks and audit

    Checks before a harmful command runs, and every command in the audit trail.

Firmware over the air

  • Roadmap

    Signed images

    Devices will install only firmware images with a valid signature.

  • Roadmap

    Staged rollouts

    Releases to a small ring of devices first, then to wider rings.

  • Roadmap

    Automatic rollback

    A device that cannot start a new image will go back to the last one that worked.

SDKs and networks

  • Roadmap

    C SDK

    For ESP-IDF, Zephyr and FreeRTOS, under an open licence.

  • Roadmap

    Arduino and MicroPython

    SDKs for the boards that makers prototype on.

  • Roadmap

    Python and Node

    SDKs for gateways, Linux devices and services.

  • Roadmap

    LoRaWAN

    Long-range, low-power devices through a network server.

  • Roadmap

    CoAP and LwM2M

    For constrained devices on limited networks.

Gateways and edge AI

  • Roadmap

    Edge gateways

    Modbus, OPC UA and BLE devices connected through gateways.

  • Roadmap

    Edge AI and model management

    AI models running on edge boxes, deployed and managed from IoT OS.

Developer experience

  • Roadmap

    Device simulator

    Virtual devices that send data before any hardware exists.

  • Roadmap

    First message in five minutes

    Guided onboarding, with a code snippet for each SDK.

  • Roadmap

    Keys and certificates

    Device keys and certificates managed in the console.

Dashboards, reports and AI

  • Available

    Dashboards

    A Dashboards tab in the IoT OS console, starting from a ready-made template: readings, alarms and the highest reading today, the average by day and the latest alarms.

  • Available

    Reports of readings and alarms

    In the IoT OS console's Reports tab: each device's readings by day, with the count, lowest, highest and average of every number field, and its alarms, as CSV, XLSX or PDF.

  • Roadmap

    Copilot over device data

    SyncVelo's Copilot, available over fleet data today, extended to device data.

The SyncVelo family

One account, products that work together

Frequently asked questions

Can I use IoT OS today?

Yes, for devices, their telemetry, their alerts, dashboards and reports. IoT OS has its own console, address and sign-in on the SyncVelo account, and organizations add it from the marketplace wherever HQ has launched it. There you create device types, give each device its own credentials, connect it over MQTT 5 or HTTP and follow its latest values, history, charts and alarms. An alarm checks one field of a reading; each time it starts holding it raises an alert, sent by email, SMS, WhatsApp or push under your organization's notification policies and to webhooks registered in the console, and the console's Alerts tab is where alerts are acknowledged and closed. The console's Dashboards tab shows figures, charts and short tables over readings and alarms, each figure beside the period before, and its Reports tab makes reports of each device's readings by day (the count, lowest, highest and average of every number field) and its alarms, as CSV, XLSX or PDF. Every other feature on this page carries its status.

Which devices does IoT OS support?

Today, any device that can speak MQTT 5 over TLS or post its readings over HTTP. LoRaWAN, CoAP and LwM2M are planned for IO4, and Modbus, OPC UA and BLE machines through edge gateways for IO5. A device type describes each kind of device, whoever made it.

How are devices and their data kept secure?

Devices connect over TLS with credentials of their own, inside a topic space that belongs to one organization; a device's secret is shown once, and new credentials end the old ones. Commands that can cause harm will need a named approval and safe-state checks (IO2), and firmware will be signed (IO3). Roles, permissions and the audit trail come from the SyncVelo platform, which runs today.

Will the device SDKs be open?

That is the plan: device SDKs under an open licence, so makers can build them into their products. C for ESP-IDF, Zephyr and FreeRTOS, Arduino, MicroPython, Python and Node are planned for IO4. The code on this page is a preview of that interface, not a released SDK.

Is it the same account as Fleet?

Yes. One SyncVelo account and one sign-in work across the consoles, with one organization tree and one HQ. An organization adds IoT OS from the marketplace where it is launched, and the product appears on its plan.

Can partners offer IoT OS under their own brand?

Partners already use white label and custom domains on the SyncVelo platform; today a custom domain opens Fleet's console. The product family is designed so that a partner's domain can open IoT OS under the partner's brand, and this page will say when that is ready.

Where does AI come in?

Two places are planned: AI models at the edge, deployed and managed from IoT OS (IO5), and SyncVelo's Copilot, which already answers questions over fleet data, extended to device data. Both are on the roadmap.

Get started

Tell us what you want to connect

Devices connect to IoT OS today, and more is being built. Tell us about your devices, and we will tell you what is ready for them and what comes next.

Book a demoStart free trialContact sales