In a previous blog article looking at radio technologies, we suggested that the winners in the race were likely to be based around Bluetooth, Zigbee and the emergent 5G technologies. Unsurprisingly, it turns out that life is more complicated than this, and there is a lot more going on within selected niches as well as elsewhere outside of the UK.

Whilst collaborating with a smart home energy saving business, OpenTRV, one of the things that becomes obvious is that it is super important in the home environment for devices requiring remote control to be able to communicate with a central/controller hub. There are number of ways of tackling this:

• Plug all the devices in, use Wi-Fi and hope that all devices can reach the home Wi-Fi hub
• Plug all the devices in, use Wi-Fi with range extender units e.g. using powerline technology
• Go battery powered and use a low power “mesh network” of devices based on Bluetooth or Zigbee technology and hope that this will help solve all nodes reaching the hub
• Go battery powered and use a low power wireless technology that has a better range in the first place e.g. sub-GHz radio based at 433MHz or 868MHz

There are different likelihoods of success and a number of pros and cons with each of these approaches: installation/wiring of sensors to an electricity supply, cost of extra connectivity units, battery replacement costs, data throughput, design margin/certainty of connections etc. In the home environment, product businesses have often tended to pick the last approach for the out of box certainty of connection and are big users of the sub-GHz radio technologies e.g. Lightwave & Mi|Home products.

Now “sub-GHz” wireless technologies may not be that familiar to people who know Bluetooth and Wi-Fi from their mobile phones, but they turn out to be surprisingly well supported by silicon vendors with a wide set of chipset offerings e.g. Texas Instruments CC1310, ST Microelectronics S2-LP, Nordic nRF-905, Silicon Labs EZR32WG, NXP MKW01Z128, Renesas RL78/G1H etc.

Silicon Labs sub-GHz evaluation board

Whilst the sub-GHz radio solutions for home sensors enjoy longer range e.g. 100m with low power, they do have the disadvantage of being unable to natively communicate with mobile phones or the internet. To do this, they need a compatible receiver box which has to be connected to the home router or Wi-Fi hub. This in itself is not a major issue as all home solutions currently rely on a physical “box” for providing the control element of the solution.

But could this box disappear into the cloud in the future? Certainly, but consumers may become worried if increasing numbers of their critical home systems lack the backup of local controls and they become totally dependent on both their broadband provider AND their home automation service’s cloud operation.

This is a modified version of an article originally published on LinkedIn here.

I made a worthwhile trip to the IoT London event (23-24^th Jan) recently to test the pulse of IoT and find out about some new and upcoming IoT product companies.

In general, I would say it felt like the scale and activity around IoT seems to have increased with a large number of participants and presentations on offer.  With so much to see and businesses to talk to, it would have been useful to have a few more chairs to sit down and catch one’s breath…

Having said that, it is appropriate that this is called the Tech Expo as I could see a lot of product innovation, but also some challenges for businesses in finding their best channels for growth. Notwithstanding, I will mention here a few of the physical product companies that captured my interest..

Nanolike is a French company taking advantage of nanotechnology to create a tiny force sensor which uses a fraction of the power of existing sensing technologies. These size and power advantages mean that there is a wide scope of deployment opportunities, perhaps new products in the quantified self area that become feasible?

BeanIoT is based in Cambridge, UK and has created a range of small autonomous “bean” sensors which can connect to and through mobile phones and other low power bluetooth based devices. The beans have batteries and can be charged wirelessly, with the battery life depending on the number and rate of measurements requested by the bean. There is a quite a wide range of sensing available in the beans: accelerometer (step counter), temperature, pressure, air quality, humidity etc. It is interesting to see such a “Swiss army knife” type proposition being brought forward, as opposed to a more single purpose accessory like a fitness tracker or a wireless weather station. The team is integrating their own cloud storage and ‘bean’ data visualisation platform so as to provide an out of box solution and broaden its appeal toward business.

OpenTRV is a UK company aiming to make a big dent in the costs of domestic heating to cash constrained consumers along with the UK’s CO2 emissions. Their products are a connected and a standalone smart radiator valve that detect presence/occupancy in a room and learn when to turn on and off the radiator. Now existing thermostatic radiator valves can be bought for about £5, but many do not work particularly well nor do they offer the same heat saving potential, with up to 30% saving being claimed. The company is looking at the most affordable product options in order to make a 1 year repayment case to also appeal to people in rental accommodation. The connected option of the valve is more expensive, but can offer “telemetry data” on energy savings e.g. for large scale housing landlords.

The last company I mention is Neurofox, a German company with a product dedicated to helping stressed people achieve a state of mental relaxation in minimum time. The product comprises a headband with 5 brain activity sensors feeding into a controller unit with a headphone audio output and a wireless connection to a pc. The idea is to use the audio feedback path to help train the users to fall into a relaxed state. Over a period of time, through personalised hints and customised feedback, the solution gets better – but how this is achieved i.e. the IoT feedback path is not quite clear yet.

In summary, the show offered an interesting mix of product innovation along with end-end IoT solution companies, data visualisation offerings, multi and wide-area sensor connectivity and connectivity management solutions.  Bearing in mind that google search does not generate a uniform distribution of winners, then for those interested in IoT companies, the list of exhibitors can be found here.

In our initial internet of things (IoT) opening post,  we said that many of the existing IoT solutions shared a common architecture. This post looks at the challenges in using one of those pieces of the architecture – the ease of use of an “off-shelf” cloud compute platform.

The essentials of an IoT system comprise of a few basic epics/user stories:

1. As a system owner, I want to be able to give my individual IoT endpoints their own unique identities so I can discriminate between them.
2. As a system owner, I want to be able to secure & restrict access to my IoT system to the endpoints that belong to me (and vice-versa).
3. As a system owner, I want to be able to define both individual and bulk policies for what IoT endpoints are allowed to do with their data when they connect.
4. As a system owner, I want to be able to define on both an individual and bulk basis what actions are to be taken as a result of IoT endpoint data transactions.
5. As a system owner, I want to be able to remotely “maintain” all of my IoT endpoints in terms of configurations and software versions.

In this initial approach to the AWS IoT platform, I concentrated on topics 1-3 and left aside the practical deployment issues for the present.

In summary, I would say that I like the Amazon approach to addressing these issues, as in a way they are the table stakes, with the main IoT value creation around what is being measured/monitored and how the data obtained is being intelligently used and combined to provide benefits.

My experience of the Amazon IoT system has focused on the IoT SDK and backend, specifically the python and embedded C versions and trialling the basic data publish/subscription over MQTT. In terms of positives & negatives:

• No special setup required to start using AWS IoT, provided you already have an AWS account. It is also free to use (at present), provided you don’t go crazy and start using millions of messages per month.
• Good initial impression of the documentation & code samples, but this soured slightly over time as a LOT of the examples & setup are tailored for the AWS IoT button as opposed to e.g. linux desktop for doing a quick test drive.
• Bit of confusion over which “C” SDK to use for the desktop test drive. It seems it should be a separate download of linux_mqttmbedtls2.1.1.tar, which is a shame as I only found this out after downloading the embedded C SDK and discovering it within the readme file.
• Very easy to “create” a new IoT device as well as certificates and keys to associate with the device to enable authenticated access to system.
• Less great in terms of specifying precisely what to use in the header files for the code samples for the device ID and access points for pub/sub testing versus e.g. long identity string for the device shadow.
• Not too well explained IoT policy concept i.e. [3] in the user stories. It is absolutely mandatory to create one of these and associate it with the certificate in order even to get connected to the IoT server.
• IoT policies are poorly documented. I had to create a very permissive policy to enable the basic publish and subscribe examples to work: with ANY of my devices I can connect / publish/ subscribe to anything.
• Calling out on the policies:
  • The documentation on identifying *which* specific IoT node in the policy is somewhat lacking. I am not able to make restrictions adequately without affecting something else.
  • Also the documentation on *what/where* the IoT device can publish/subscribe to is also lacking. There needs to be a better definition of the vocabulary & syntax for the policy statement.

AWS IoT console

Other than these initial problems, probably due as much to my own specific knowledge base, the AWS offering looks good in terms of getting started fast and providing the basic plumbing for an IoT system. Ian Massingham gave a good presentation on AWS IoT at Hardware pioneers in October.

Naturally AWS are looking to monetise IoT through use of their other cloud assets, storage, processing, machine learning and it will be interesting to compare in another blog against Windows Azure IoT which requires a chargeable server reservation for the right to use IoT.

Jan 2017 – update

I can now take back some of what I said earlier about the difficulty of finding the allowable policy definitions for IoT devices interacting with AWS’s backend. They were there in the documentation if you looked for them.

Excluding the “shadow” (Amazon’s virtual copy of the IoT device to use when e2e connections are broken), there are 4 fundamental actions and 3 different types of resource to query the action against.

In summary of the policies:

• We can restrict connections according to the IoT device ID.
• We can prevent messages being sent to the IoT device(s) or limit them to certain topic groups.
• In a combined policy statement with connect, we can limit the IoT devices able to receive messages from certain topic groups.
• We can limit the topics where IoT devices are able to publish to.
• In a combined policy with connect, we can link the device id-topic pair publishing combination e.g. a destination specific to each client.
• Ditto for subscriptions.

And there seem to be plenty more policy resource query variations in the documentation available using “variables” for some more advanced use cases.

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.

This article reviews the issues when considering the choice of radio technologies when building Internet of Things systems. Our previous article proposed there were two radio technology selections to be made:

• An ultra-low power technology to connect sensor nodes with gateway nodes to enable battery powering for ultra small devices.
• A longer range technology to connect gateway nodes with the internet.

Ultra low power radio technologies

Given that a typical sensor node will be battery powered without re-charge over a period of the order of years, there is massive requirement for an extremely low power solution. Several radio technologies have been developed with this application in mind – of particular note Bluetooth Low Energy and Zigbee/Thread.

The case for Bluetooth is built on the universal availability of this standard in smart phones so allowing these devices to act as either gateways to cloud application, control points for the IoT system or data aggregation/display nodes for non-cloud connected cases.

The case for Zigbee and its Thread variant is built on their optimised design for connecting sensors and particularly their ability to create a mesh network which potentially extends the effective operating range of a gateway node.

Bluetooth SIG is aiming to close these functional gaps in the Bluetooth 5 release which is due late 2016 early 2017, promising in addition to mesh networking increased range. Timing is often critical for the process of choosing winning technical standards, but in this case it seems the whole IoT market has been dormant in a state of great expectation already for a number of years and therefore not a critical issue for Bluetooth.

Ultimately the winning radio standard in this case is likely to be decided by the role of the smart phone in the IoT ecosystem – if it plays an important role then Bluetooth solutions will dominate, if not then it is likely there will be less consolidation into  a single radio type.

Longer range radio technologies

For the RF connection between the gateway node and the ‘internet’, the availability of a local WLAN network has typically between the key factor driving choices as a Wi-Fi signal will usually mean lower costs and power consumption than using cellular. Indeed, Ericsson has estimated that nearly 90% of IoT devices will NOT be connected over cellular. However 5G is being designed with IoT in mind and therefore it may offer a more cost effective and robust communication solution than today’s cellular solutions, yet expectations are that this technology will not be widely available until after 2020*.

Long range IoT is currently dominated by a number of proprietary solutions such as SigFox and LoRa which have emerged to fill a gap of combining long range and low power. The price of this combination is to really cutback on data rates offered to a single node, which suits a lot of the contemporary machine to machine applications. Because of the very low bandwidth per node and their relatively long range, these solutions can be made to be a very economic solution for many applications.

Looking at past experience with mobile telephony, standardised radio solutions drive opportunities to create economies of scale and if operators create economic packages of IoT users then it is likely 5G will dominate in the long term.

*Verizon in the USA is aggressively driving 5G wireless trials and targets some early commercial deployments in 2017 for fixed site application i.e. fibre/cable replacement role, not mobility and not necessarily the scope of 5G required for lowest power IoT.

There is a huge amount of hype related to the internet of things as we have already explored in a previous blog.

However in its current state the IoT market consists primarily of a myriad of proprietary solutions optimised for a given application; with these conditions it does not seem likely that IoT will deliver on the hype around it. If that situation changed and standardised radio interfaces were used along with general purpose hardware modules which could be purposed for  application by software alone then the market could explode.

In order to make the internet of things realise its potential it is imperative that the creation of networks is both straight-forward and low cost.

The availability of wireless enabled computing elements such as the Raspberry Pi or ultra-low power elements such as the Nordic nRF52 promise to enable the creation of Internet of Things systems with very low cost and great configurability. However the reality of creating such systems is more complex than it might be.

Raspberry pi 3 with built-in wireless capability

Types of wireless compute elements

There are fundamentally two types of autonomous compute elements in IoT networks:

• Battery powered without frequent re-charging. The over-arching design objective is minimise energy and power consumption (to use primary cells or perhaps solar charging) which prevents the use of current WLAN technologies and drives a demand to minimise processing on-board. The relevant RF communications candidates for these devices are Bluetooth and ZigBee/Thread. Generally speaking these elements require an intermediate gateway to connect to the internet. These elements will be referred to as sensor nodes.
• Mains powered or battery with frequent re-charges. In this category ultra-low power is not a driver, RF link technologies such as standard Wi-Fi, proprietary (e.g. SigFox) or cellular are most appropriate to connect to the internet. Included in this category potentially are smart phones. These devices may either gather data themselves or else harvest it from the ultra-low power devices detailed above; in which case as well as possessing radio technology to connect to the internet, they must also contain radio technologies such as Bluetooth or ZigBee. These elements will be referred to as gateway nodes.

Connecting up

For a typical IoT application in addition to the elements detailed above the following are required:

• A wireless router or a cellular base station connected to the internet.
• A cloud application to aggregate, analyse and display data. In addition this application can also monitor and control the nodes in the network.

For this system to work in a ‘fully horizontal’ manner the interfaces between each element should be well defined and published and could therefore be connected like ‘lego’. However there are certain challenges which need to be overcome. The key questions which need to be initially addressed are:

1. Choice of radio technology to connect the nodes.
2. Choice of higher level communications protocol to gather/deliver information between the nodes and the internet based cloud application.

These two questions will be addressed in further blog posts appearing here.