Platform Concepts

It's just MQTT

When you connect a device to OhioIoT, you're not learning a proprietary protocol or a custom API. You're connecting to an MQTT broker — the same publish/subscribe messaging system used across the IoT industry. Any standard MQTT client can connect. Any MQTT reference you find online applies here.

What OhioIoT adds on top of that is a set of topic conventions that the dashboard knows how to interpret. If you publish to a topic in the right shape, the platform will automatically graph it, log it, or surface it in your device dashboard. You don't have to use any of that — but it's there when you want it.

Tenant isolation

Every OhioIoT account is fully isolated. Your devices, topics, and data are invisible to every other user on the platform. This is enforced at the broker level through ACLs — not just by convention.

The rule is simple: every topic you publish or subscribe to must begin with your MQTT username. The broker will reject anything that doesn't. There is one exception: broadcast/# is a read-only namespace that OhioIoT uses for platform-level announcements. You can subscribe to broadcast/beacon, but you cannot publish to it.

# valid — starts with your username
larry/thermostat_01/numb/temperature/temp

# invalid — broker will reject this
someone_else/thermostat_01/numb/temperature/temp
temperature/temp

Topic structure

Beyond the username prefix, your topics are your own. You can publish tolarry/anything/you/want and it will reach any subscriber listening to that topic. Structure them however makes sense for your project.

That said, the OhioIoT dashboard listens for topics in a specific shape and does something useful with them. The conventions are based on the third segment of the topic, which tells the platform what kind of data is being sent:

Breaking down the structure:

larry / thermostat_01 / numb / temperature / temp
  │         │           │         │              │
  │         │           │         │              └── field name (series on the graph)
  │         │           │         └── graph name (groups fields together)
  │         │           └── data type: numb | bool | status | config
  │         └── device ID (your own identifier, any string)
  └── your MQTT username (required on every topic)

For status and config topics, there is no graph name — the key goes directly in the fourth segment and the value is the payload:

larry / thermostat_01 / status / firmware
  │         │              │         │
  │         │              │         └── key shown on device card
  │         │              └── status (read-only values reported by the device)
  │         └── device ID
  └── your MQTT username

larry / thermostat_01 / config / setpoint
  │         │              │         │
  │         │              │         └── key shown on device card
  │         │              └── config (settings the device echoes back)
  │         └── device ID
  └── your MQTT username

Subscribing

You can subscribe to any topic under your own username using MQTT wildcards:

larry/#                          # everything under your namespace
larry/thermostat_01/#            # everything from one device
larry/thermostat_01/numb/#       # all number data from one device
broadcast/beacon                 # platform broadcasts (read-only)

broadcast/beacon is the one topic outside your namespace you're allowed to subscribe to. OhioIoT uses it for platform-level announcements. You cannot publish to it.

Ready to go deeper?

Now that you understand the topic conventions, pick your next step: