Smart to Social – Evolution of Social IOT

Sridhar krishnan

Sridhar krishnan

Things, the smart objects turn to social objects to boost the pace of IoT emergency and to make it more universal. The relationships of co-location, co-ownership, co-work and parental among friend objects provide a platform to share services, information, computing, and other resources and output. This modern promising paradigm of technology extension is called Social Internet of Things (SIoT). An inevitable aspect of SIoT is the convergence of smart objects and social media that can introduce new social interactions by enabling the things to have their own social networks and interactions. The smart objects can establish their social relationship based on their activities, interest, and profile.

Here are the three main facets of an SIoT system:

  1. The SIoT is navigable. We can start with one device and navigate through all the devices that are connected to it. It is easy to discover new devices and services using such a social network of IoT devices.
  2. A need of trustworthiness (strength of the relationship) is present between devices (like friends on Facebook).
  3. We can use models like studying human social networks to also study the social networks of IoT devices

Basic Components

In a typical social IoT setting, we treat the devices and services as bots where they can set up relationships between them and modify them over time. This will allow us to seamlessly let the devices cooperate among each other and achieve a complex task.

To make such a model work, we need to have many interoperating components. Let us look at some of the major components of such a system.

ID: we need a unique method of object identification. An ID can be assigned to an object based on traditional parameters such as the MAC ID, IPv6 ID, a universal product code, or some other custom method.

Meta information: along with an ID, we need some meta information about the device that describes its form and operation. This is required to establish appropriate relationships with the device and appropriately place it in the universe of IoT devices.

Security controls: this is like “friend list” settings on Facebook. An owner of a device might place restrictions on the kinds of devices that can connect to it. These are typically referred to as owner controls.

Service discovery: such kind of a system is like a service cloud, where we need to have dedicated directories that store details of devices providing certain kinds of services. It becomes very important to keep these directories up to date such that devices can learn about other devices.

Relationship management: this module manages relationships with other devices. It also stores the types of devices that a given device should try to connect with based on the type of services provided. For example, it makes sense for a light controller to make a relationship with a light sensor.

Service composition: this module takes the social IoT model to a new level.
With SIoT, things can publish information and services, find information and services and get environment characteristics that can be used to achieve the following,

Communal sharing – Behavior of objects with collective relevance

Equality matching – Objects operate as equals and requests/provide information among them in the perspective of providing IOT services to users while maintaining their individuality

Authority ranking – Established between objects of different complexity and hierarchical levels

Market pricing – Working together with the view of achieving mutual benefit. Participation in this relationship only when it is worth the while to do so.

The goal of having such a system is to provide better-integrated services to users. For example, if a person has a power sensor with her air conditioner and this device establishes a relationship with an analytics engine, then it is possible for the ensemble to yield a lot of data about the usage patterns of the air conditioner. If the social model is more expensive, and there are many more devices, then it is possible to compare the data with the usage patterns of other users and come up with even more meaningful data. For example, users can be told that they are the largest energy consumers in their community or among their Facebook friends.



How to Series Blogs: Connect ESP 8266 / NodeMCU to AWS IoT


Srinidhi Murthy

In this Blog we talk about connecting the simple ESP 8266 / NodeMCU to AWS IoT. Traditionally the simple and easily available ESP 8266 based boards could not connect to AWS IoT. There are two issues that prevent the use of AWS IoT for ESP8266 Arduino and pretty much every other 8-bit microcontroller-based device.

One is the requirement to either support certificates or uses a crypto library to create “signatures”.

The other is TLS 1.2 or higher. If they allowed TLS 1.1 and added a “pre-shared key” authentication system, similar to the rest of the IoT providers’ de-facto standard for devices like these, there would already be another billion devices on the net.
AWS IoT supports web-sockets with MQTT now, which works on ESP 8266 / NodeMCU but not guaranteed.
This is all about to change … Enter the ESP-OPEN-RTOS ….

The ESP-OPEN-RTOS, a community developed the open source FreeRTOS-based framework for ESP8266 WiFi-enabled microcontrollers. This RTOS is intended for use in both commercial and open source projects. Using the ESP-OPEN-RTOS, we have the ability to create a simple event driven RTOS for controlling all Things in the near field via Wifi and also has the support needed to create signatures and supports TLS 1.2 … which means connection to AWS IoT is possible.

ESP-OPEN-RTOS can be installed on any Linux based server like Ubuntu, RHL, SuSE and using the Xtensa tool chain can be cross compiled for ESP 8266 based boards like NodeMCU / Adafruit HUZZAH etc.

The procedure for installing the ESP-OPEN-RTOS, the pre-requisites, necessary SDK’s, toolchain etc is given in detail in the link.

We are not going to delve here on installing the RSP-OPEN-RTOS or the necessary software / SDK. We are going to concentrate on the RTOS Itself and its ability to connect to AWS IoT.

Let’s quickly move to the examples section of the ESP-OPEN-RTOS where we find the AWS IoT example.

Connection to AWS IoT needs the AWS command line Interface to be installed to create policies to allow the Thing (ESP 8266 / NodeMCU) to connect and an ECC based Certificate and private key .pem file to be generated. The detailed procedure is highlighted below.

  • Modify client_config.c to provide your own account-specific AWS IoT endpoint, ECC-based client certificate, and private key.
    1. Your endpoint is in the form of <prefix>.iot.<region> It can be retrieved using the following command:
      1. $ aws iot describe-endpoint
    2. Your ECC-based certificate and private key can be generated by using the following commands:
      1. $ openssl ecparam -out ecckey.key -name prime256v1 -genkey
      2. $ openssl req -new -sha256 -key ecckey.key -nodes -out eccCsr.csr
      3. $ aws iot create-certificate-from-csr –certificate-signing-request file://eccCsr.csr –certificate-pem-outfile eccCert.crt –set-as-active
    3. To convert the certificate or key file into C string, you could try the following example:
      1. $ cat ecckey.key | sed -e ‘s/^/”/g’ | sed -e ‘s/$/\\r\\n”/g’
        Note, more information about using ECC-based certificate with AWS IoT can be found in the following blog
  • Create and attach AWS IoT access policy to the certificate
    1. $ aws iot create-policy –policy-name test-thing-policy –policy-document ‘{ “Version”: “2012-10-17”, “Statement”: [{“Action”: [“iot:*”], “Resource”: [“*”], “Effect”: “Allow” }] }’
    2. $ aws iot attach-principal-policy –policy-name test-thing-policy –principal “arn:aws:iot:eu-west-1:892804553548:cert/2d9c2da32a95b5e95a277c3b8f7af40869727f5259dc2e907fc8aba916c857e”
      Note, the ‘principal’ argument is the certificate ARN generated from the previous command ‘aws iot create-certificate-from-csr’.
  • Modify include/ssid_config.h with your Wifi access Id and credential.
  • Build and flash the example firmware to the device using the command below:
    1. $ make flash -C examples/aws_iot ESPPORT=/dev/ttyUSB0
      Note, it assumes your ESP8266 is connected through USB and exposed under your Linux host as /dev/ttyUSB0.
  • Once the ESP8266 is connected to AWS IoT, you can use the MQTT client on the AWS IoT console to receive the messages published by the ESP8266 to topic ‘esp8266/status’. You could also publish ‘on’ or ‘off’ message to topic ‘esp8266/control’ to toggle the GPIO/LED (GPIO2 is used by the example).

IOT Solution Architecture Styles


Chandramouli Srinivasan

There are many ways to architect the Internet of Things implementations for enterprises. CIOs must consider security, privacy, cost, ease of access, agility and performance to determine the best architecture for each enterprise.

Enterprises will build and adapt their Internet of Things implementations based on a combination of these five main architecture styles:

  • Thing-centric. Things are smart on their own and store most of their data on-board. Things are self-sufficient and communicate to the Internet only for centralized coordination and analysis.
  • Gateway-centric. The gateway houses the application logic, stores data and communicates with the Internet for the things that are connected to it. Things don’t have to be as smart because the gateway provides these resources.
  • Smartphone-centric. The smartphone (or any mobile device) houses the application logic, stores data and communicates with the Internet for the things that are connected to it. Things don’t have to be as smart because the smartphone provides these resources.
  • Cloud-centric. The cloud will act as the central connection hub, power analytics, and provision data storage. Things don’t have to be as smart because the cloud will provide these resources
  • Enterprise-centric. Things are behind a firewall and are geographically collocated. There is little need to extend out to the external Internet.


Each architecture has its own advantages and disadvantages. These architectures are designed to be style models that most enterprises will want to combine according to their needs. The reason why the names of each of these architectures are appended with “centric” (for example, cloud-centric) is that we expect that most enterprises will not pursue a pure implementation. For example, an enterprise might favor a smartphone-centric architecture, but may still rely significantly on cloud resources.

Enterprise CIOs and IT leaders should use these steps as a way of thinking about how to implement these architectures:

  1. Find the architectures that fit your use cases. Use the criteria in the Choosing the Right IoT Architectures section. Expect to have different use cases that require different architectures within the same enterprise.
  2. Choose or build an IoT platform that can support these chosen architectures — (ideally, all architectures, even the ones you won’t adopt immediately).
  3. Consider emerging technologies that may eliminate the advantages and disadvantages of an architecture style. For example, high-performance messaging protocols (for example, Data Distribution Service remove the latency in the cloud to provide real-time communications as if the machines were locally close. The cost of computing, storage, and communications will also be an emerging factor. For example, a decreasing cost of hardware against a rising cost of communications would influence an enterprise toward a thing- or gateway-centric style, as opposed to a cloud-centric style.

Choosing the Right IoT Architectures by Prioritizing Constraints

To properly evaluate which architecture styles fit best, enterprise CIOs and IT leaders should consider the following criteria. There is no right answer. Often, what is perceived as an advantage in some situations (for example, using cloud resources to remove cost and complexity from things) is actually a disadvantage in other situations (for example, connecting to the cloud is problematic or less secure).

The Priority constraints that needs to managed are

  1. The cost of hardware, software, and data.
  2. Connectivity & technical requirements based on reliability and quality of service; Real-Time Performance.
  3. Data and Security.
  4. Users and Implementations complexity.