This page contains detailed information about the AWS IoT Core service in the IoT Bridge. This service lets you integrate LPWAN devices as things in AWS IoT Core. The IoT Bridge acts as a proxy, when you call an action related to a thing in AWS IoT Core, a connection will automatically be established if it is not already connected. The connection will expire and will be disconencted after the expiration period defined in your AWS IoT Core service definition.
The AWS IoT Core connector establishes individual MQTT connections for each deviceId that is requested. Devices are authenticated by having a shared CA between IoT Core and IoT Bridge. With the trust of the CA, each device is assigned a unique certificate signed by the shared CA and all subdequent connections utilize the generated certificate. Should you ever need to reset the certificates in use by the IoT Bridge, you must delete the IoT Core instance and create a new one to allow certificates to be re-created.
The AWS IoT Core service contains the information required to establish a service connection to AWS for the purpose of dynamically creating and retrieving device configurations.
This event fires when the IoT Bridge establishes a connection to IoT Core.
{
"thingName": "device001"
}
This event fires when the IoT Bridge disconnects a thing from IoT Core.
{
"thingName": "device001"
}
This event fires when the IoT Bridge receives a job changed notification from IoT Core.
{
"thingName": "device001",
"jobId": "my-job",
"status": "IN_PROGRESS",
"statusDetails": {
"detail1":"my detail"
},
"jobDocument": {
"targetFirmware":"2.0.1"
}
}
QUEUED, IN_PROGRESS, SUCCEEDED or FAILED.This event fires when the IoT Bridge receives a shadow changed notification from IoT Core. The IoT Bridge creates 3 change objects within the event that help describe the changes between the current and previous values of the shadow to facilitate faster processing.
{
"thingName": "device001",
"shadowName": "my-shadow",
"changes": {
"same": true
},
"desired": {
"fanSpeed": 5000
},
"desiredChanges": {
"same": true
},
"reported": {
"fanSpeed": 5000
},
"reportedChanges": {
"fanSpeed": {
"new": 5000,
"old": 4900
}
}
}
same: true if the desired and reported objects are the same.same: true indicates that the desired shadow did not change.same: true indicates that the reported shadow did not change.This event fires when the IoT Bridge sends a publish to IoT Core.
{
"thingName": "device001",
"topic": "telemetry/device001",
"topicParts": ["telemetry", "device001"],
"payload": {
"temperature": 25.4
}
}
This event fires when the IoT Bridge receives a publish from IoT Core.
{
"thingName": "device001",
"topic": "telemetry/device001",
"topicParts": ["telemetry", "device001"],
"payload": {
"temperature": 25.4
}
}
Connect a thing in AWS IoT Core immediately.
// Connect now
aws_iot.connect('myservice', 'mything')
Disconnect a thing in AWS IoT Core immediately.
// Disconnect now
aws_iot.disconnect('myservice', 'mything')
Subscribe to MQTT topics on the fly. Note that the number of topics must match the number of qos values supplied.
// Subscribe to the topic device/mything/inbound with QOS 0.
aws_iot.subscribe('myservice', 'mything', ['device/mything/inbound'], [0])
// Subscribe to the topic device/mything/inbound with QOS 0, note the [thingName] field will be replaced automatically.
aws_iot.subscribe('myservice', 'mything', ['device/[thingName]/inbound'], [0])
Unsubscribe from MQTT topics on the fly. If a topic is not already subscribed, no error is returned.
// Unsubscribe from the topic device/mything/inbound.
aws_iot.unsubscribe('myservice', 'mything', ['device/mything/inbound'])
Publish a message to IoT Core on a specified topic. Note that objects will be converted to JSON.
// Publish a message to a topic with QOS 0.
aws_iot.publish('myservice', 'mything', 'device/mything/outbound', { temp: 26.5})
Update a named or classic shadow.
// Update the desired shadow for a thing to set the fan speed to 5000 RPM
aws_iot.shadow_update('myservice', 'mything', 'myshadow', { fanSpeed: 5000}, null)
// Update the reported shadow for a thing to set the fan speed to 5000 RPM
aws_iot.shadow_update('myservice', 'mything', 'myshadow', null, { fanSpeed: 5000})
// Update the reported classic shadow for a thing to set the fan speed to 5000 RPM
aws_iot.shadow_update('myservice', 'mything', '', null, { fanSpeed: 5000})
// Remove fanSpeed from reported shadow properties
aws_iot.shadow_update('myservice', 'mything', 'myshadow', null, { fanSpeed: null})
null to clear it.null to clear it.Update an IoT Job, either marking a queued job in-progress, or continuing the progress to keep it alive.
// Update a job to be in-progress with 10% progress.
aws_iot.job_update('myservice', 'mything', 'myjob', 30, { progress: 10 })
Update an IoT Job, either marking a queued job in-progress, or continuing the progress to keep it alive.
// Publish a message to a topic with QOS 0.
aws_iot.job_update('myservice', 'mything', 'myjob', 30, { progress: 10 })
Topics can be specified using variable substitution to permit simplified handling and processing at runtime. This can ease the logic of creating customized subscription patterns when configuring your devices.
To properly handle jobs, you need to handle the different stanges of the lifecycle. This provides you an opportunity to provide information during the execution of the job.
If you create a trigger that fires when the aws-iot-core-job-changed event fires, it will get all lifecylce events for the job. If you supply a body like:
if(event.data.status=="QUEUED") {
aws_iot.job_update(event.service.key, event.data.thingName, event.data.jobId, 5, {mydata: 'something'})
} else if (event.data.status=="IN_PROGRESS") {
aws_iot.job_complete(event.service.key, event.data.thingName, event.data.jobId, true)
}
You will get default behavior that receives a job in the QUEUED state, and updates it to in-progress. Then when a new status update of IN_PROGRESS is received it will mark the job as complete. Obviously this is most likely not what you would use in production, but for an example, it shows the basic lifecycle.
The following events are considered billable:
Once established, connections will automatically reconnect until the activity timer expires. This can create issues if you attempt to connect to IoT Core using the same thingName as the two will continue to compete for the connection.