Second Week Report
Google Cloud IoT Core - Concepts study
A thorough study of Google Cloud IoT Core concepts is required in order to develop Lua based APIs for it.
The main components of Cloud IoT Core are the device manager and the protocol bridges:
- A device manager for registering devices with the service, so you can then monitor and configure them
- Two protocol bridges (MQTT and HTTP) that devices can use to connect to Google Cloud Platform
So we will see the following IoT Core Concepts in brief
- IoT Core Protocols
- IoT Core Security and Authentication
- IoT Core Devices, Configuration and State
IoT Core Protocols
Cloud IoT Core Supports two Protocols:
- MQTT : Standard publish/subscribe protocol that is frequently used and supported by embedded devices and is also common in machine to machine protocols.
- HTTP : A ‘connectionless’ protocol. Devices don’t retain a connection to cloud IoT Core, they send and receive responses
The Choice of protocol can be made using the following comparative study of both the protocols
IoT Core Security
Cloud IoT offers the following architecture to ensure the device to device or device to core service or core service to device security:
The further Authentication is managed via:
- The JWT is signed by private key with the authentication flow.
- MQTT bridge and device see the ‘JWT’ as the password in the “MQTT connect”.
- MQTT bridge verifies the JWT against the device’s public key.
- MQTT bridge accepts the connection and closes it when JWT expires.
IoT Core Devices, Configuration and state
- Device Registration :
- In order for a device to connect it must be first registered in the device manager.
- Device manager lets you create and configure device registries and the devices within them.
- Device manager can be accessed through the cloud platform console, gcloud command line interface or the REST-style API.
Device registry is a container of devices
A registry is identified in the cloudiot.googleapis.com by its full name as :projects/{project-id}/locations/{cloud-region}/registries/{registry-id}
A Device registry is configured with one or more cloud pub/sub topics to which telemetary events are published for all devices in that registry.
A Single topic can be used to collect data accross all regions.
-
Devices :
- When a device is created within a registry, it is defined as a cloudIoT core resource.
- Each device is identified by its full resource name: projects/{project-id}/locations/{cloud-region}/registries/{registry-id}/devices/{device-id} OR projects/{project-id}/locations/{cloud-region}/registries/{registry-id}/devices/{device-numeric-id}.
-
Device Identifiers :
- A device-id defined by the user.
- A server-generated device numeric-id created by cloud iot core.
- Full path of the device.
-
Device Metadata :
We can define metadata for a device, such as hardware thumbprint, serial number, manufacturer information, or any other such attribute.
-
Device Configuration :
- With Cloud IoT Core we can control a device by sending a device configuration to it.
- Device configuration is a user defined blob of data sent from Cloud IoT Core to a device.
- MQTT bridge and HTTP bridge are two configuration versions.
-
Device State :
- Device State information captures the current status of the device, not the current environment.
- Devices can describe their state with an arbitrary user-defined blob of data sent from the device to the cloud.
The Information that needs to be sent to or from a device should not be stored as a device metadata because device metadata stays in the cloud.
The information should be in a device configuration if we need to send it to a device, or in device state data if we need to report it back to cloud iot core.
Using the device configuration one can :
1. Send a device's expected state as a configuration.
2. send a command to a device.
Initial Github Repository and weblog
The github repository for the initial release of APIs in lua can be found here
Build a basic weblogging site using jekyll and github pages is also up and running