MQTT bridge to IoTF

Hello I am trying to connect several devices to IoTF using a broker bridge with mosquitto. The scenario should be like this: few devices are publishing/subscribing to a local mosquitto broker; all devices are registered in the IoTF as devices. The local broker creates a bridge connection to IoTF broker and forwards devices messages. I don't understand how should I register the local mosquitto broker in IoTF: as a device or as an application? If I register it as an application, how do I remap the topics so the devices can publish using normal pattern to IoTF? Does IoTF broker supports bridges?

3 answers

Typically, when a device connects to IoTF with a client ID of 'd:org:device-type:device-id' and publishes a message on the topic 'iot-2/evt/event-id/fmt/format-id', an application can receive it (with an applicable subscription) on the topic 'iot-2/type/type-id/id/device-id/evt/event-id/fmt/format-id'.

It's important to note that in this case, the device's publish topic does not contain the type or ID of the device (it is instead read from the client ID).

So, my question would be; "How does your bridge work?".

If your bridge is a simple one-to-one proxy (a device connecting to the bridge means the bridge makes a new client to talk to IoTF), then providing you forward the correct client ID (and credentials), you should be fine - your bridge will just look like many devices to our service (beware of connection throttling - repeated 'bad' connections from one IP address may reduce the priority of handling further connection attempts).

If your bridge is a many-to-one thing (you can have any number of devices connecting to the bridge, but there will be exactly one client talking to IoTF), then... it's complicated.

You can get the bridge to work by connecting as an application. Applications can publish 'as-a-device' - which will work to your advantage - with a topic string like 'iot-2/type/type-id/id/device-id/evt/event-id/fmt/format-id'. If enabled (and the format is 'json'), messages published here will be stored in historian for the device your application is pretending to be.

However, how your bridge can extract the device type and ID from the incoming device connections will be up to you.

Also, connection monitor messages won't be published (as the device didn't actually connect/disconnect) - so, if you had applications listening to device connection status updates, you'll need a new way to do this.

Without more specific details on how your bridge works, it'll be hard to tell whether it will work or not. Hopefully, one the cases I outlined above will meet your usage.

If not, can you clarify on how messages will be forwarded (particularly in regards to which clients will connected to the IoTF)?

My scenario is actually the second case described by you and now I understand that the bridge is just a client that my local broker is using to pub/sub to IoTF. I have been testing it with success yesterday evening using the Broker as a registered application. I think it will work for us as I don't see big problems at the moment, but is true that we are loosing some features like connection monitoring as you specified.

Let me add some more complexity: I am using the local broker behind a router on an embedded linux device that get a local IP address. The devices that are connected to it are low power devices, so I don't want to keep the TCP connection alive, but still I want to be able to receive commands from IoTF. In this case, the broker is handling that. Now, to solve the issue with the connection monitor, I was thinking to develop a MQTT message router parsing the different topics from the devices and sending them to IoTF with the device credentials, but that means there is no persistent TCP connection with the IoTF broker and I can't receive commands. Is this correct? Is there a solution to this? Could it be that IoTF adds a new type of device (broker/router) that can handle this kind of message distribution (many to one, many to many).

So, your devices won't always be connected but you want to receive commands anyway?
In this case, you should use durable subscriptions (your client sets the clean session flag to false and subscribes to the command topic with a QoS of at least 1). This way your devices can rejoin the action and get brought up to speed nicely.

You have a good point here, thank you. But using the broker means that, on the local network, the broker can initiate the connection to the 6LowPAN embedded device (I am planning to use the current Contiki MQTT client) and have some kind of (near)real time messaging. The solution you are suggesting looks like some kind of pooling, but it could work very well on some slightly different scenarios.Also, using a local broker has the advantage of having much smaller delays between the 6LowPAN devices and the edge router running the broker, less power consumption on the sensors for communication. I have experienced large delays with a GPRS edge routers, but a broker has the capability to manage those issues.

Actually, in this case, I am planning to have the devices use the application topics e.g. SUB to iot-2/type/t/id/i/cmd/c/fmt/json So the devices will use the the topics normally used by the applications, but only on the local broker. It makes life much easier, at the moment. But in the feature I might use the IoTF broker directly and it will be a bit confusing to manage the same topic in a different way. The only problem I can see is the one related to the applications registered on IoTF is there any restrictions or cost related stuff to this?

Are there any restrictions or cost related stuff to using applications?

Currently (everything is subject to change), Yes and No.

If you are using a Bluemix Free organization or an SBS Trial organization, you will only be allowed to create a limited number of api-keys. However, you can use the same api-key as many times as you like (as long as you use different client IDs).

There is currently no limit on message throughput (but all messages must be smaller than 4KiB).

As for cost... Sadly, that's not my area of expertise, so if you need an answer on that, I'll need to fetch somebody else (do you want me to do this?).
If you're using Bluemix Free/SBS Trial - you should not be billed (otherwise, those plan names are confusing).