This is the second blog in a series looking at the complexity of using well known cloud compute platforms for building solutions for the Internet of Things.

Summary

The IoT “rules” and “actions” within AWS IoT are what allow you to bring your IoT data to life within the cloud through associated AWS services.

My first observations about setting these up gave me the sense that this was going to be quite tricky- using the AWS command line interface to craft new roles and policies to be able to use different AWS services.

However, this setup work is now starting to get a whole lot easier, with the introduction of a set of guided UI steps in the IoT suite which make it easier to accomplish the end goal. I was able, with relatively little effort, to setup publishing using an IoT program on a client to create IoT data files in the AWS storage cloud and make these publically visible on the web.

Whilst saying this, I experienced a few odd quirks from the platform e.g. when trying to configure IoT automated actions. Whilst I can’t claim strong knowledge of the platform, the reasons for the issues were far from clear and it may well be that there is just one way of doing things.

My feeling is however, that it would be a small step from here to have the client program running on a reasonable scale embedded platform e.g. one with Wi-Fi/IP stack. Indeed, the AWS IoT button is a good example and AWS themselves reference a number of other suitable hardware platforms.

AWS have a number of services to connect with the IoT platform e.g. database and simple notification services which are bundled under a somewhat “vertical” navigation scheme; it is a shame that the service “worked examples” are rather spread around the AWS documentation, meaning that the problem you are trying to solve may have an answer, but you can’t always see it from your current silo.

AWS IoT platform rules & actions

In a previous blog, I looked at the basic epics and user stories for an IoT system and cross referenced the experience with the AWS IoT platform. This previous blog only touched on the basic connection experience with AWS IoT: configuring end-points with identity certificates, setting up the target internet access point and enabling the basic data publish policy on the cloud end. These are represented by the greyed out boxes in the initial block picture.

This piece is an initial look at the next step operations possible with the AWS IoT system:

• Defining a rule to filter all the published IoT topic data
• Creating an action related to the rule e.g. data file/database update

Note: As a company looking to make a solution with a number of real “autonomous” IoT end points, quite a number of other tasks remain beyond what I have mentioned in the blogs so far e.g. visualisation, endpoint update, non-functional performance, alternate wireless connectivity (BT, LoRa) etc.

Initial thoughts

The rules and actions seem to be the most quirky part of the IoT system so far: I noticed that one of my new rules/actions stored in the cloud seems to have disappeared/deleted itself and then re-instated itself on the following day. Strange.

From my experience in trying to use AWS IoT rules and actions, it is best to follow AWS’ precise recommendations.

• Setup an account with AWS (account “owner” – access all areas including billing)
• Set up an administrator account under AWS IAM (all areas w/out billing)
• Make/configure everything else whilst logged in as administrator i.e. all AWS IoT, “thing”/ device names, certificates & access policies.
  • After creating devices/certificates as the account owner, and other items as the admin, I had some odd behaviour with rules/actions not being executed and files being created yet not being visible to me as “administrator”.

The picture shows some of the SQL syntax used for specifying the topic of interest to work with and a SQL “WHERE” condition can provide further filtering on the topic data content – it is typically looking for key-value pairs with more details in the IoT developer guide.

The next stage in the dialogue, the selection of an action to result from an IoT rule is shown in the picture above e.g. creating files in S3 storage.

The selected action must be configured and the above picture shows the s3 action configuration. The first boxes are to specify or create the S3 bucket where the IoT data will be written along with the sub-directory/key. If a new bucket is needed then an s3 management console is opened to enable this.

The lower box enables the selection of a “role” with an appropriate associated permissions policy to execute the action. Interestingly the “create a new role” most often did not work for me i.e. fails to load the IAM management console. To work around, I used an existing role which had the s3PutObject policy, and used the “update role” button to add the new s3 bucket/subdirectory to the role permission – see the picture below.

This odd behaviour is an example of there is perhaps just one way of doing things at present i.e. when using the rule wizard, it appears to prefer to re-use existing roles with s3 access as opposed to creating additional roles.

Having been through the setup experience, it is clear to me that to get most value from AWS IoT rule and action deployment, you need to get to know the rest of AWS’ solution offering e.g.

• Identity access and management (IAM) as an enabler
• Simple storage service (s3) for storing data
• Lambda (“serverless” execution) for manipulating data
• Simple notification service for messaging and alarm notifications

This should not be surprising as most of these solutions are also “chargeable services” in their own right, with the IoT providing the on ramp for customers. This familiarisation process is going to involve a certain amount of time investment, but the payback potential is evident and the examples within each service silo are generally good and worthwhile to try out.

A future blog will contrast our experiences with Microsoft Azure IoT with those of AWS IoT.