We’re temporarily disabling the email triggers until we can make them more robust in a near future update. In the meantime, the alternative would be to use our IFTTT channel, which can do pretty much the same thing as our internal trigger emails.

We want to build a much more robust system. As is, there are some weaknesses in our current design that can trigger emails to be sent far too often, or without a way for them to reset after the trigger threshold has been hit.

If you have any suggestions on what you’d like to have implemented with this feature, please let us know at the our IO forum.

This week we will be deploying two major changes to IO. We will be deploying v2 of the REST API, and we will be moving our MQTT services from mosca to aedes. This should allow us to squeeze even more performance out of our MQTT workers, and will also allow us to support MQTT QoS 2.

Here are the stats for the past week:

* 28.69 million inserts of logged data in the last 7 days
* 10,512 users
* 8,077 online feeds (22,695 feeds total)

Here are the stats for the past week:

* 30.21 million inserts of logged data in the last 7 days
* 10,086 users
* 7,766 online feeds (21,498 feeds total)
* ~50 inserts per second via MQTT
* ~5 inserts per second via REST API

After some load testing, it seems that our current server configuration is able to handle more traffic. Our current theory is that the inserts per second aren’t rising evenly with the increased online feed count because users are using IO for real-time interaction, and not data logging. Inserts per second only seem to rise with heavy and persistent data logging projects.

We have been testing the new Feather LoRa Radios with IO, and they seem to be a fantastic pair. We were able to send messages to IO through a LoRa gateway from 1.27 miles away in the rolling hills of central Maryland using a small wire antenna.

Pretty impressive for not having line of sight to the gateway!

We added support for AWS v4 inspired request signing to IO’s v2 REST API this week. This change should allow devices that don’t support TLS/SSL to communicate with Adafruit IO without sending their AIO Key in the clear. Because the requests are signed using a HMAC, users also will be able to ensure that their requests were not manipulated by things like man-in-the-middle attacks. This change will also reduce the risk of replay attacks by including a timestamp in the signature, so the request will only be valid within a 15 minute window.

We are considering requiring signed requests for any API v2 requests that don’t use a TLS/SSL connection. If you think this is a bad idea, please let us know in the forums. We will be updating the Adafruit IO client libraries this week to support the new request signatures.

Here are the stats for the past week:

* 27.4 million inserts of logged data in the last 7 days
* 9,744 users
* 7,537 online feeds (20,474 feeds total)
* ~50 inserts per second via MQTT
* ~5 inserts per second via REST API

Inserts per second seem to be holding steady, despite the increase in online feeds. We are going to add another queue worker and monitor the inserts per second to see if that fixes the bottleneck.

We have been working on finishing up v2 of the REST API this past week, and you can read more about that here.

We are also in the process of finishing up transitioning our frontend javascript to React from jQuery and Backbone. When combined with API v2, this change should increase performance, and also will make development easier and faster. We will post more about this change in the next few days.

Here are the stats for the past week:

* 25,951,672 inserts of logged data in the last 7 days
* 9,296 users
* 6,949 online feeds (19,084 feeds total)
* ~50 inserts per second via MQTT
* ~5 inserts per second via REST API