Playing around with some of the current open-source offerings for measuring data (like MQTT and Node-RED) has me wishing all IoT devices supported custom MQTT server configuration.

That is, I want every IoT device to allow me to add one (or more) additional (assuming they use MQTT out-of-the-box) MQTT brokers, such that whatever data the IoT device sends to its servers as it comes from the vendor, it also sends to the configured MQTT broker.

Motivation

Doing this enables at least a couple of things:

  • I can get at the raw data to use as I see fit.
  • I can access the data in purely local network.

Sure, I might already have had access to the data through their API, but this means learning a new API for each device. NodeRED makes this easier of course, because you can usually make a flow that polls their server periodically, massages the data, and then feeds it into your data collection system. But you still have to spend time figuring out APIs, often with authentication challenges. And most significantly, these solutions almost always require Internet access. Which brings me to the second benefit:

A custom-configured MQTT server can exist on the local network. Which means all those IoT devices become usable on, say, a boat in the middle of the Pacific. Or a cabin in the woods. Or my house when my ISP goes down.

Finally, it’s probably a much easier implementation to add an MQTT client (if the device doesn’t already use MQTT) than to add a REST API in the cloud or on the device, even with the large number of authentication options available.

What Should Be Configured?

So what do we want to be able to configure, at a minimum? I think the following should be largely sufficient:

  • A name or IP address of any MQTT broker.
  • Whether or not the connection must be secure (but it should support both).
  • Verious means of securing the MQTT broker connection (private cert, key, psk, etc).

  • A topic prefix.

    This starts to get into the most nebulous part of my proposal: if an IoT device already uses MQTT, it probably already has one or more topics it publishes. Those might conflict with topics from other devices on an arbitrary server, so providing a topic prefix might let the device owner better organize things. If an IoT device vendor wants to let me configure all their topics, great. But I don’t think that’s necessary.

  • And nice to have? A switch that lets me say “only send data to this broker.” This would disable the device’s other data channels (e.g. whatever server they would normally use).

Importantly, the device shouldn’t refuse to function if it can’t phone home. This might run afoul of more complex DRM or activation schemes a vendor might cook up, but I think for the vast majority of devices, it should be fine.

If an IoT vendor wants to make more things configurable, even better! But these basics should go a long way toward interoperability and ease of integration.

What do you think?