Note: The library has now been updated to 2.6.0 with this required change.

There is an important update to the Adafruit IO Arduino client library that will be released tomorrow. We will perform this update as a coordinated update with the SSL certificates for io.adafruit.com. The client library contains an SSL fingerprint that checks the validity of the connection.

You will need to download the library update, and then compile/upload to your devices once the update is released tomorrow. We will update this post once the update has been pushed.

Here are the stats for the past week:

* 76.4 million inserts of logged data in the last 7 days
* 30,188 users
* 25607 online feeds (88,417 feeds total)

The biggest new feature is a new download system for your data. It’s a more robust way to download your data and doesn’t make you wait for it to complete, along with a few other neat features. If you want to try it out, visit your feed or settings page to download your data.

We’ve also updated our throttling algorithm. Please see this post for more details.

Another update that we can talk about is that we are that we’re currently working on our Ruby and Python client libraries. Porting them to the api v2, and adding new features. If you want to play with alpha/beta code, feel free to check those out in their respective repository and api-v2 branches.

We’re continuing to work on a few major new features, but we aren’t quite ready to talk about them yet.

We’re also responding to issues you may run into on our Adafruit IO Forum. Please post any issues with as much detail as you can. It definitely helps us out when fixing the bugs.

Also, if you’re still using version 1 of our API, you may want to upgrade to the latest version 2. It has more features, and is generally better designed and easier to use than our previous API. The default for our docs is V2 now as well.

We’re changing throttling in Adafruit IO for the better. We’re moving from a fixed-window, long period throttle rate that can lock out clients for up to 15 minutes in some cases to a rolling-window, short period throttle rate that can reset sooner when clients are well behaved.

In the past, hitting our authentication or data limits could result in a lock on your account for up to 15 minutes. If you’ve ever seen the red bar at the top of your browser window while you’re working on an IoT project, that was most likely a throttle. The short explanation for that is that we were using a fixed-window throttling algorithm that resulted in message bursting when we made the window of time too small. The best solution we had at the time was to make the window longer, which resulted in the 15 minute lock-outs mentioned above.

With our new system, very similar to the one described here, once you’re throttled on authentication or sending data, stopping sending will be guaranteed to reset your throttle in less than 1 minute. The tradeoff is that continuing to send messages at a greater-than-limit rate will cause you to remain throttled forever. Where the old system would let you back in for authentication after 15 minutes, the new system could lock you out forever if you have a large enough collection of misbehaving devices you’re unable to stop.

To avoid being throttled, make sure you set delays on all reconnection attempts of at least 10 seconds and make sure you’re sending at most 1 message per second across all your devices and browser sessions. For example, our Arduino library delays for 60,000 milliseconds between reconnection attempts after it’s been throttled. Client libraries will let you post data as fast as you’d like, so it’s a good idea to keep a subscription to the MQTT $username/throttle topic open somewhere you can see it while you’re writing code.

Some additional benefits of the new system going forward:

• We can now manage throttling across the MQTT and HTTP APIs.
• We now have a few additional variables we can tweak to make the experience of building an IoT device or application nicer. For example, we can set minimum distances between messages and scale the rate/window to smaller slices (10 messages / 10 seconds rather than 60 / 60). We’ll be keeping an eye on throttling once we’ve deployed the new system.
• Refactoring our throttle logic lets us customize throttle rates across accounts, which will support Adafruit IO paid subscriptions in the future.

It’s tricky to be brief, but we put a lot of thought into changes like this and we like to share. :D

Please speak up on the forums with any questions or thoughts. We’d love to hear how you’re using IO!

Here are the stats for the past week:

* 84.7 million inserts of logged data in the last 7 days
* 29,181 users
* 24,509 online feeds (84,764 feeds total)

Since our last State of IO post, we’ve been mostly heads down on new features that aren’t quite ready yet for production. We’ve also made some major performance improvements to our backend that has helped with general system stability.

We’re also responding to issues you may run into on our Adafruit IO Forum. Please post any issues with as much detail as you can. It definitely helps us out when fixing the bugs.

Also, if you’re still using version 1 of our API, you may want to upgrade to the latest version 2. It has more features, and is generally better designed and easier to use than our previous API. The default for our docs is V2 now as well.

Here are the stats for the past week:

* 80.2 million inserts of logged data in the last 7 days
* 27,729 users
* 23,248 online feeds (79,685 feeds total)