I’m pleased to announce that you can now send and receive data to and from devices over HTTP with the IBM Watson IoT Platform. This is in addition to the existing support for MQTT.

Thanks to the wide availability of HTTP clients in almost all environments, in every language, on every platform – being able to use HTTP for connectivity just makes connecting things easier.

Whether you’re sending events to the platform or receiving commands from the platform now you can use HTTP between the device and the cloud.

Sending events

Example: To securely send an event called ‘myEvent’ to the platform with organisation id ‘xfd8ls’, device id ‘HTTPDevice’ and device type ‘HTTPdeviceType’ then issue this POST request:

https://xfd8ls.messaging.internetofthings.ibmcloud.com:8883/api/v0002/device/types/HTTPdeviceType/devices/HTTPDevice/events/myEvent

The body of the message is the event you want to post. ¬†You need to use Basic Auth, specifying ‘use-token-auth’ as the userid and the device’s token as the password.

Receiving commands

Example: To securely receive any command for the device ‘HTTPDevice’ with a device type of ‘HTTPdeviceType’ in the ‘xfd8ls’ organisation then issue this post request:

https://xfd8ls.messaging.internetofthings.ibmcloud.com:8883/api/v0002/device/types/HTTPdeviceType/devices/HTTPDevice/commands/+/request

As with events you need to use Basic Auth, specifying ‘use-token-auth’ as the userid and the device’s token as the password. ¬†If there’s a command waiting then you’ll get it back as the body of the response message, if there isn’t then you’ll get a return code of 204.

HTTP isn’t as good at¬†being sent data from the server side as a bi-directional protocol like MQTT. ¬†Most HTTP communication is driven from the client side, rather than the server. ¬†From the above example, you’d have to keep polling the server to see if there was a message waiting. ¬†That’s slow and computationally expensive. ¬†For some use cases that’s fine – where you’re trying to conserve power, and just wake up periodically to check whether there’s a message waiting for you. ¬†For other use cases you want the command to arrive as soon as¬†it is sent. For that you can issue what’s often called a long poll.

Set the body of the message to:

{"waitTimeSecs": 10}

The number represents a number of seconds. ¬†It tells the server to hold on to the request and only respond back if there’s a message or the number of seconds elapses. ¬†That way you can effectively set your code to ‘wait’ for a command to arrive.

Give it a try!

See the full documentation.

This functionality is currently in beta, we welcome your feedback.

Join The Discussion

Your email address will not be published. Required fields are marked *