IoTHubQuota Exceeded

TH 6 Reputation points
2021-05-03T09:09:56.723+00:00

Im a developer with many years experience, but a newbie to azure and to python

I am working on an IoT project where I have a number of Raspberry Pi units sending telemetry data to Azure. To facilitate this I have set up the following in the cloud

1 x IoTHub, F1 - Free
1 x Stream Analytics job

On my raspberry pi units, I have written some client (in Python) that send data to my hub.

All seems to fine until I exceed my message quota (8k per day on F1 tier). Once this happens, each attempt to send a message from any device, results in that device hanging. I need to handle this as I cant have all of my field units disabled if message quota limits are reached. I know that I can upgrade my IoTHub to give me more messages, but the question will still arise once I reach the limit of the pricing tier that I select.

My code (simplified) is...

client = IoTHubDeviceClient.create_from_connection_string(connectionString)
message = Message(messageTemplate.format(....))
client.send_message(message)

once my IoTHub message quota has been exceeded, the client.send_message(message) instruction hangs

Can someone advise on the recommended way of dealing with this.

Thanks

Azure IoT Hub
Azure IoT Hub
An Azure service that enables bidirectional communication between internet of things (IoT) devices and applications.
1,115 questions
Azure Stream Analytics
Azure Stream Analytics
An Azure real-time analytics service designed for mission-critical workloads.
330 questions
0 comments No comments
{count} votes

4 answers

Sort by: Most helpful
  1. Sander van de Velde 28,311 Reputation points MVP
    2021-05-03T13:24:03.12+00:00

    Hello @TH ,

    You are using the Free tier version of the IoT Hub. where an S1 version is capable of receiving 400.000 D2C messages a day of size 4KB, the free tier support 8000 messages of size 0.5 KB. Sending C2D messages and Device provisioning is also part of this amount.

    Keep in mind that sending a message with a size of 700 bytes is counted as two messages.

    To work around this, there are a few options:

    • Obviously, the S1 offers quite a lot more messages for ~1 dollar a day. Plus you can scale up and down if this is needed for some reason
    • The Azure IoT SDK offers to send messages as a batch in C#. This way the use of the number of messages is more efficient if you batch more messages together and fill up the 'empty spaces' (up to 256KB in one go) I'm not sure if this is the case with Python too (You can submit a feature request)
    • you can consider making your code resilient by queueing messages to be sent to the cloud at a later moment when sending messages is possible again (at the end of the day). The Azure IoT Edge has built-in temporary storage already.
    • You can try to zip the message:

    93308-image.png

    1 person found this answer helpful.
    0 comments No comments

  2. TH 6 Reputation points
    2021-05-04T06:56:11.73+00:00

    Thanks @Sander van de Velde

    I will try this later today. I had thought that I had done something like this without success. I will revisit later. I am a c# developer and so using python is not totally in my comfort zone. I will check the libraries I am using and use the strategy you suggest

    1 person found this answer helpful.
    0 comments No comments

  3. TH 6 Reputation points
    2021-05-03T21:04:47.42+00:00

    SandervandeVelde42
    Thanks for response. I have been considering how I might make more efficient use of my message quota but I guess what Im looking to understand right now is what happens to the messages that I send from my client device to the hub once my quota has been used up? And the question remains regardless of whether I opt for the free tier (8k messages per day or as you mention, the S1 tier (400k messages). Once I exceed my quota, my client code hangs when I attempt to send a message.

    I was wondering if there is a way in my IoT Hub to say for example

    • ignore any messages once quota exceeded and return a response in a timely fashion the the client code indicating "full for today, come back tmoro" (silly but Im sure you get the point)
    • or queue messages and process them once the next quota cycle begins (but again return a response in a timely fashion the the client code indicating "full for today, we will process tmoro"

    You mentioned in your respnse...
    "you can consider making your code resilient by queueing messages to be sent to the cloud at a later moment when sending messages is possible again (at the end of the day). The Azure IoT Edge has built-in temporary storage already."
    How would I, in client code, determine if sending messages is possible.

    Thanks in advance for any further help

    T

    0 comments No comments

  4. Sander van de Velde 28,311 Reputation points MVP
    2021-05-03T21:49:45.857+00:00

    Hello @TH ,

    In the client code, you can check for the reason why the IoT Hub rejects your messages.

    One of the errors the IoT Hub can throw is "403002 IoTHubQuotaExceeded".

    I tried it myself with this C# application:

    93423-image.png

    I sent messages with 500 words of Lorum Ipsum :-)

    After more than 2000 messages (which is way over 8000 message chunks because each message was 3.5 Kb) the application stopped:

    93414-image.png

    I got an exception:

    93325-image.png

    I checked the inner exceptions and I ended with:

    "{\"errorCode\":403002,\"trackingId\":\"bbaada88155048a292830be0a51dab0e-G:0-TimeStamp:05/03/2021 21:30:08\",\"message\":\"Total number of messages on the IoT Hub exceeded the allocated quota. Increase units for this hub to increase the quota. For more information on quota, please refer to: https://aka.ms/iothubthrottling\\",\\"timestampUtc\\":\\"2021-05-03T21:30:08.0951258Z\\"}"

    With the C# IoT Hub Device SDK, I am able to check for the exact error with that unique error number:

    93431-image.png

    Yes, this is an example in C#. I expect you could do something similar in Python by catching the (inner) exceptions.

    0 comments No comments