Azure IoT Hub – Routing

In IoT projects it is quite typical that devices either are from different types or they send messages of different types. No matters the reason, IoT Hub ends up receiving different types of messages.

Before routing features existed, all the messages were treated through a single “pipeline” and eventual routing operations were coded “by hand” over that unique pipeline. Nowadays, things have changed and IoT Hub includes native routing features.

Let us see what it does and how it works.

 

Endpoints

Endpoints can be reached and defined from IoT Hub’s left-side menu (Messaging Section).

IoT Hub’s Messaging Menu

 

Endpoints management page allows to:

• create custom endpoints
• configure custom endpoints
• delete custom endpoints
• configure built-in endpoints
  • Default events endpoint
  • Cloud to device feedback endpoint
  • File upload notifications endpoint

 

NOTE: the number of custom EndPoints is limited (as of now, 10 per IoT Hub)

 

Creating a custom endpoint is pretty straightforward. It only requires:

• an endpoint name
• choosing its type
  • Event Hub
  • Service Bus Queue
  • Service Bus Topic
  • Azure Storage Container

 

IoT Hub – Endpoint creation

 

Routes

Once endpoints are created, it is time create the routes. The process is pretty simple too:

IoT Hub – Route creation

It requires the settings below:

• A route name
• Data Source type:
  • Device Messages
  • Twin Change Events
  • Device Lifecycle Events
• Endpoint (one of the previously created or a built-in endpoints)
• Query string the routing is built over

 

Queries are written in a T-SQL-like language and based on:

• message properties (kind of message metadata properties, settable by IoT SDK when building messages)
• message content properties (usually, more related to the business core of the project)

 

Ex:  status = 500 and $body.messageType = ‘error’

 

Built-in routes

IoT Hub includes built-in routes that deserve a couple of words:

• Default route, where devices’ messages go through by default
• File upload, that can be used by devices to upload “big” messages (ex: any kind of media, collection of messages stored locally, etc).
• Twin notifications, could be used by IoT Hub every time a twin is updated, in order to monitor or notify changes
• Device lifecycle, used by IoT Hub to notify device lifecycle oriented messages (ex: device created, deleted, disabled, enabled, etc)

 

Things to keep in mind

If in your project, routing queries need to be based on messages’ content, keep in mind it must be “understandable”. Some device manufacturers or MCUs may have no choice and could send hexadecimal messages (or under any other custom serialization format).

Queries can be based on message properties too.

 

Conclusion

Routing feature is really useful (literally used in all real world projects I have been involved in since the feature was rolled out). It offers the possibility to build separate and customized treatment workflows, depending on message types and project requirements on them.