Solved the most critical issues found in the process of connecting systematically and with robustness between the PSoC6 IoT thing and the AWS IoT Core, the first task is completed. Now, the second important part is to proceed in the Super Smart Home cloud architecture setting to provide a reliable way to manage the received data and visualize them in a well-structured container.
I aim to create a cloud model whose data are useful not only for the activity of monitoring but also to get valuable information to optimize the home maintenance costs.
I should say that the identification of the right procedure to complete the process from the PSoC6 MQTT data sending up to the data visualization has not been easy. I passed the past Sunday connected with shabaz jancumps making experiments and tests trying to understand the right setting and finding all the issues. When on Sunday morning Jan wrote to me he was having some time free that day, I am almost sure he was not supposing how he was about to spend his free time.
The SiteWise Architecture
AWS for IoT offers several kinds of solutions to manage the IoT Core information. For example, it is possible to monitor the data with the AWS Analytics, which is one of the most diffused but this service is oriented to manage a kind of feedback-response, like triggering events while what I need is a complete monitoring system including data calculations. To follow a dashboard approach for data visualization I opted for the AWS SiteWise service.
Above: the SiteWise centralized architecture to collect the remote IoT MQTT data from the IoT Core endpoint(s) for monitoring and calculation.
This system can receive data from several providers, not only the IoT Core and can provide a wide series of structures organized hierarchically; describe as an efficient and fast to implement a method to control data sets inside an industrial plant can be easily adapted to work with different family data coming from a full home monitoring. Another reason for my choice depends on the modularity of the Super Smart Home design: the model I am building is dimensioned to control my own home but the same group of sensors and data structures can be implemented in many living contexts that – for example, like in a condominium – share a considerable quantity of monitored resources like gas, heating, water, etc.
The SiteWise Assets
External data, in this case coming from the IoT Core things, should be injected to SiteWise filtered through Assets. This is the key component of this service; the several and not necessarily coherent data coming from the remote things to the AWS IoT Core are linked to the SiteWise assets that act as a series of selectors for the RAW data. Another important feature of the assets is the possibility to define calculations on the data series so as a matter of fact, they act as a sort of intelligent containers to structure and prepare the data for representation.
The above scheme shows how the data collected into SiteWise assets can be managed through a wide series of properties, including formulas and notification processes. It is almost frequent that with a large number of IoT things the same asset needs to be used for different groups of data. For this reason, assets are created based on Assed Models, an abstraction of the data groups, including the applied calculations. Models can be used to generate many assets connected to the thing that will receive the data (see image below).
Based on the Asset Models settings and properties assigned to them every Asset filter, collects, and organizes the IoT Raw data providing a specific representation along the timeline.
Connecting the IoT RAW data to the SiteWise assets
The connection between a SiteWise Asset and the IoT data in the AWS IoT console is done by a Role, When defining a role in the AWS IoT Core, it will contain an Action, so when the role is connected to an asset the data received – stored in an internal database – are extracted with an SQL SELECT defined in the role action.
The recognition of the right group of MQTT topics and their certification is done through a Policy; instead of simply defining the kind of topics and the thing parameters we should expect to accept the data, in this case, the thing policy also defines a series of shadows: these a sort of timestamped variables connected to their respective Assets.
For every shadow defined in the thing policy (don't forget that the policy is also authorized by the secured connection as it should be associated with the thing certificate), the last received topic shadows are persisted and can be visualized in the Shadow menu option of the thing object from the AWS IoT Core console, as shown in the above image.
Also, the PSoC6 connection procedure and topic sending should be changed accordingly to manage the shadow fields definition; to do this it has been useful the MQTT shadow project included in the Cypress AWS RTOS to which I referred to set the next procedure.
SiteWise Data Representation
As shown in the images below, SiteWise does not only give the assets content monitoring but can also automatically create a Portal; it is a website where the assets are organized in projects to represent several structured, hierarchical dashboards, for the full control of the entire IoT architecture.
The above images show the screenshots of the Super Smart Home portal created with SiteWise. The next step consists in the creation of the other nodes to organize the data to be sent and monitored by the portal with the two main gateways: the Cypress PSoC6 WiFi Bt and the Raspberry Pi Control Center.
Already Posted (until now)
Sources, Circuits, and Documentation
All the software sources, scripts, circuits schematics, and more are available as Open Source material on the SuperSmartHome GitHub repository.
The video episodes of this challenge are repurposed on the blog posts of the site we-are-borg.com
Element14, AWS, and Cypress, main sponsors
Elegoo for 3D printers ad printing material
Digitspace for sensors, actuators, and boards