By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post

How to get last heartbeat and last event telemetry for a thing in AWS IoT using Javascript SDK

0

Hello,

I'm trying to figure out a straightforward way to get the last heartbeat time (last timestamp a device connected to the MQTT broker) and last event time (last timestamp a device sent telemetry data) and last state time (last timestamp it reported on its state), through the AWS Javascript SDK.

In Google IoT Core I can call the iot.v1.DeviceManagerClient.getDevice() passing the devicePath to it and will return, among other things, this three timestamps I mention. Here https://cloud.google.com/iot/docs/reference/cloudiot/rest/v1/projects.locations.registries.devices the keys 'lastHeartbeatTime', 'lastEventTime' and 'lastStatusTime' are in the response.

For getting a device in AWS IoT Javascript I'm currently using IoT.describeThing() passing the thingName to it and returns this response object https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Iot.html#describeThing-property.

How can I make an API call through the Javascript SDK to get these three timestamps in AWS IoT Core?

This is for use in a web app to show information for our devices. Note that I don't want to make a subscription to the lifecycle events topics, I just want to trigger an API call via the SDK when a user request for information on the device in my web app, to show the latest timestamps for these three properties.

Thanks in advance, as I haven't found anything online regarding this!

Topics
Internet of Things (IoT)
Tags
AWS IoT Core
Language
English
Nicolas Gorga
asked a year ago466 views
2 Answers
0

Hello Nicolas.

With Google IoT, it seems that "device state" and "telemetry events" are published to special topics: /devices/DEVICE_ID/state and /devices/DEVICE_ID/events. These are Google conventions and these topics have no special meaning in AWS IoT. Are you migrating devices from Google to AWS? If so, and you can't change the device firmware, you will likely need to use AWS IoT Rules to subscribe to these topics and a Lambda to process these messages, storing the timestamp in a storage service of your choice.

Within AWS IoT, device shadows is probably a good choice (somewhat dependent on fleet size and message frequency). The shadow documents include timestamps and/or you could use the timestamp() SQL function in the rule. In your web app, you would use getThingShadow. If you can change the device firmware, you may consider to make the devices publish device state directly to the shadow reserved topics: https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-mqtt.html.

If shadows are not suitable, DynamoDB is another good option.

The time at which the last heartbeat was received is essentially just the corollary of whether the device is connected or not. If a PINGREQ has not been received for 1.5 PINGREQ intervals, the device will enter a disconnected state. You're aware of the lifecycle events, but please be aware of this sample that stores the status in DynamoDB: https://github.com/aws-samples/connectivity-management-example-for-aws-iot-core. The sample could be altered to instead store in shadows, and with an event timestamp (bringing connectivity, device state and telemetry event timestamps together in once place for your web app).

Side point: you linked to documentation for V2 of the JS SDK. You might consider to use V3 instead.

profile pictureAWS
EXPERT
Greg_B
answered a year ago
  • Nicolas Gorga
    a year ago

    Hey Greg,

    I created a Lambda function that gets triggered whenever there's a message posted to the topic 'devices/+/events' (our devices post to the topic 'devices/{deviceId}/events' telemetry, as discussed due to current implementation with GCP IoT), and in the SQL query statement i 'Select timestamp() as eventTimestamp, topic(2) as deviceId'.

    The function code extract this pieces of information from the 'event' object and store the timestamp for the corresponding deviceId in our Firestore Database collection for IoT Devices if the timestamp is newer than the currently stored one. With this I sort the 'lastEventTime' attribute.

    Now, for the 'lastHeartbeatTime', after checking the DynamoDb sample I see it stores the connected or disconnected timestamp, but what I need is the heartbeat as defined by you, the most recent Ping request. Using the lifecycle events, for devices that are disconnected, the timestamp I get from the 'disconnected' event is in fact the lastHeartbeatTime, but when a device is connected, storing the timestamp of the 'connected' event as the lastHeartbeatTime is incorrect, as the true value would be the latest Ping request for the ongoing connection.

    After searching I see the Ping request is handled internally by the broker and it's clients and it's not posted to any topic, so it makes me think I have no chance to construct the 'lastHeartbeatTime' attribute accurately, not for connected devices at least.

    What do you think?

0

Hello Greg,

Thanks for the quick response! I'm trying to make a migration yes, but i find that things that were quite straightforward with Google's solution is not so with AWS. It's a bit weird to me having to take care of persisting this information and also triggering a rule every time a device posts telemetry data to store the timestamp (at least for the metric of 'lastEventTime'), but if there's no other simpler option I guess it is what it is.

I'll check the sample! Yes, sorry about the link, I noticed that and started checking v3. If you have time, I would love to ask some more questions to see what you recommend, let me know if you're up for it

Nicolas Gorga
answered a year ago
  • Greg_B EXPERT
    a year ago

    You can ask new questions here on re:Post. Don't be shy on upvoting and accepting answers to ensure people are motivated. :-)

    i find that things that were quite straightforward with Google's solution is not so with AWS

    If your devices were built for AWS in the first place, they would likely publish to shadow topics and this would be similar to what you experience for device state, and possibly telemetry events.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions

Relevant content