Introduction & Use Case:

Today, we’ll look at the free tiered Azure IoT Hub’s most significant limitation - the custom endpoint bottleneck - and how to solve it!

While building a logic app to automate alerting for my IoT devices (see next article), I came across a conundrum that restricted the number of devices for whom I could forward logs to… - the endpoint bottleneck I call it - and solved for it with (you guessed it) another logic app!

👉 Note: This follows up on a previous post where we built a Raspberry Pi based soil sensor and onboarded it to Azure IoT Hub, then sent that data to a Log Analytics Workspace.



In this Post We Will:

  • 👉 Identify the Endpoint Bottleneck 🍾
  • 👉 Build a custom route and endpoint for the Message Data 📨
  • 👉 Configure IoT Hub Permissions 🔐
  • 👉 Build a Logic App to Parse Message Data for multiple devices 📊
  • 👉 Make the most of the free IoT Hub tier 💪



The Endpoint Bottleneck:

Sure, the Azure free IoT Hub allows for up to 500 registered IoT devices, but you need a custom route and endpoint in order to transmit that data across a service bus to a workspace… I know, tricky stuff…

Typically, you would send data from a registered IoT device to IoTHub, which then sends the data across a service bus to a custom endpoint (one per IoT device) in order to finally get that data into a Log Analytics Workspace. You can register up to 500 IoT Devices in the free IoTHub, but you can only have 1 custom endpoint until you upgrade to a paid tier.

If we think of this like a simple closed circuit, we can solve for this by sending all the sensor data simultaneously, across the same route, using the same endpoint and circumvent this issue.

What we’re essentially doing here is… instead of using a separate route and endpoint for each sensor’s data stream coming across Azure IoT Hub, we’re sending everything together all at once and using a simple logic app at the end like a multiplexor (MUXer) in order to split the data back out per device when it hits the workspace. Check it out!



Hardware Setup:

See previous post for hardward setup…



Build a custom route

Create an IoT route to direct messages to the Service Bus queue, as illustrated below. See Create an IoT route and disable Routing Query for more on IoT routes.



Build a custom endpoint

This is the endpoint that your data arrives at. For additional information around custom endpoints, check out Create an IoT custom endpoint.

Here’s the configuration I used for my soil sensor setup…



Permissions Configuration

Set permissions as follows:

  • RBAC: Assign the role of IoTHub Subscription Owner.
  • Expected Permissions: ServiceBus Writer at the Service Bus resource level

IoT Hub needs write access to these service endpoints for message routing to work.

💡Pro-Tip: If you configure your endpoints through the Azure portal, the necessary permissions are added for you.



Build a Logic App to Parse Message Data for multiple devices:

Setup your Trigger: Depending on your setup, you’ll probably want this trigger twice as long as your sensors are set to deliver… in this example, my sensors are set to transmit data every 10 minutes, so defining the Queue Name, Type, and Max Message Count as illustrated below will cover our use case:


Formatting your message Bas64ToString(…) works for our purposes, so use the expression to decode the message from Base64 format:

base64ToString(triggerBody()?['ContentData'])


Parse JSON - Create a JSON object from the sample JSON data. Define your “Temperature,” “Moisture,” and “Hostname” variable types…


Name the Log table and Send the Data (include the hostname; in this case it’s based on the “PepperName: Body Hostname x”)

💡 This part is critical for leveraging multiple sensors, as it allows us to split out the readings per hostname from the service bus and get around the custom endpoint limitiation… 👇



👉 Note: I had to adjust the previous python code that runs on the sensor microcontroller so that it sends the hostname along with the sensor data, illustrated in the snippet screen grab below. You can find the updated code here (just swap out your secrets etc.) SensorCode.py



Try it out!

Kick off the Sensor.py script on your sensors, then navigate to the Logs blade in your Log Analytics Workspace and run the following query to check on your peppers:


💡Pro-Tip: If you want the script to keep running after closing out your terminal session (because who wants to stare at the terminal and burn that bandwidth right?), use the nohup command (“NO Hang UP (NOHUP) Signal”) to kick off your script.


Data is now flowing from our sensors across Azure IoT Hub through a Service Bus and Custom Enpoint, on to a Log Analytics Workspace via Logic App! 😎



Conclusion:

Thanks for reading! With this configuration, you can securely leverage the free Azure IoTHub for multiple sensors simultaneously (bypassing the single service endpoint bottleneck) without breaking the bank!


🌱 🌿 What will you grow next? 🌼🌻



In this Post We:

  • 👉 Identified the Endpoint Bottleneck 🍾
  • 👉 Built a custom route and endpoint for the Message Data 📨
  • 👉 Configured IoT Hub Permissions 🔐
  • 👉 Built a Logic App to Parse Message Data for multiple devices 📊
  • 👉 Made the most of the free IoT Hub tier 💪



Next Time:

  • We’ll build some automation (playbooks 📒) to swiftly address incidents when logged data values breach predefined thresholds. In this case, I’d like automated alerts ⚠ for when my plants are too hot 🔥, too cold ❄, or too thirsty 💧.



www.hanley.cloud