AWS IoT Device Provisioning

0

I am near the end of the development cycle for an Alexa voice controlled IoT hardware product. The product consists of a microcontroller that connects to AWS and subscribes to a single MQTT topic.

There is one physical device with a single microcontroller, but the microcontroller is actually controlling 4 different mechanically actuated switches. The Lambda function is triggered by a simple Alexa Smart Home skill. The Lambda function creates 4 devices when the skill is loaded. The Lambda function is publishing to the topic that the microcontroller is subscribed to. The function is also writing to a DynamoDB table for device status. It all works together very well. The hardware device responds to voice commands as expected,

TLS device certificates are installed on the microcontroller. My plan starting out is to create a new Thing and download the certificates to each device as I build them. I am, assembling the printed circuits boards by hand. Creating Things one and a time and loading the certs on the microcontroller is how I plan to start out until it is no longer feasible to do so.,

Where it becomes rather unclear to me at this point is what happens as additional devices are created and shipped. For example.

I will...

  1. Assemble the printed circuit board and install the firmware onto the microcontroller.
  2. Create a new Thing in the AWS IoT console, download the certificates and install them on the microcontroller.
  3. Ship device to customer.
  4. They will add my Alexa Skill to their account.

I am expecting that this is all that will be required, but I am not sure. I will do further testing installing the product from scratch on other networks, but this post is ahead of that.

Is the Thing device interacting with MQTT broker and DynamoDB associated with their account or mine via account linking?

Ultimately, I am trying to make sure that I have done this right so that multiple devices are not all subscribed to exactly the same MQTT topic and DynamoDB table where one voice command controls everyone else's device.

RS
posta 4 mesi fa642 visualizzazioni
2 Risposte
4

1. Thing Creation and Certificate Management Each IoT device needs its own unique Thing in AWS IoT. This includes unique certificates for secure communication. The steps you outlined for creating a Thing and downloading certificates are correct.

Steps:

Assemble the PCB and install firmware.

Create a new Thing in the AWS IoT console. Generate and download certificates for the Thing. Install the certificates on the microcontroller.

Ship the device to the customer.

2. Account Linking and Skill Registration

When a customer adds your Alexa Skill to their account, the Alexa Skill should interact with your backend (AWS Lambda, DynamoDB) using account-specific data. This ensures that commands are directed to the correct device.

3. Isolating MQTT Topics

To prevent cross-device interference, you must ensure each device uses a unique MQTT topic. A common approach is to include a unique identifier (such as the Thing Name) in the topic structure.

Example Topic Structure:

Device 1: home/device1/command Device 2: home/device2/command This way, the Lambda function can publish messages to specific devices based on the unique topic.

4. DynamoDB Structure

Each device’s status should be stored separately in DynamoDB. You can achieve this by using a unique partition key for each device.

Example DynamoDB Schema:

Partition Key: DeviceID (unique identifier for each device) Attributes: Status, LastUpdated, etc. This structure ensures that each device’s data is isolated and accessible based on the unique DeviceID.

5. Provisioning Process Automation As the number of devices grows, manually creating Things and managing certificates will become impractical. Automate the provisioning process using AWS IoT Fleet Provisioning.

Automated Provisioning Steps:

Create a Provisioning Template in AWS IoT. Device Manufacturing: Each device should have a unique manufacturing serial number. Device Bootstrapping: When a device first boots, it connects to a bootstrap MQTT topic, retrieves its provisioning configuration, and then transitions to its unique operational MQTT topic. 6. Security Considerations Rotate Certificates Regularly: Implement a mechanism for certificate rotation to enhance security. Secure Storage: Ensure that certificates and keys are securely stored on the device. AWS IAM Policies: Use least privilege principles for IoT policies attached to each Thing.

7. Customer Registration and Device Association When the customer registers the Alexa Skill, implement a registration flow to link their account to the device. This can be done using:

Alexa Account Linking: Use OAuth2 for linking customer accounts with your backend. Device Registration API: Provide an API endpoint where the device sends its unique identifier and customer information to register and link the device with the customer’s account.

ESPERTO
con risposta 4 mesi fa
  • I am not quite sure how to actually implement #3. I understand how to include the Thing name in the topic definition on the device. However, I do not understand how to include the Thing name reference in the Lambda function. Currently it looks like this.

    var iotTopic = "device_topic";

4

Hello, The Things (devices) you create in the AWS IoT console are associated with your AWS account. Each device will interact with the MQTT broker and DynamoDB using credentials tied to your account. Your customers will not have direct access to or control over these devices via their Alexa accounts unless you specifically implement functionality for that purpose. Therefore, you are responsible for ensuring that each device is properly provisioned and secured within your AWS environment.

https://aws.amazon.com/iot-core/getting-started/

i hope this will helpful

profile picture
ESPERTO
con risposta 4 mesi fa
  • Thank you and it helps clarify somewhat. Please see my comment to Thanniru. Its referencing unique device topics from a common Lambda function that I am not sure how to implement.

Accesso non effettuato. Accedi per postare una risposta.

Una buona risposta soddisfa chiaramente la domanda, fornisce un feedback costruttivo e incoraggia la crescita professionale del richiedente.

Linee guida per rispondere alle domande