matwerber1 / aws-alexa-smart-home-demo

End-to-end demo of Alexa Smart Home Skill, including AWS IoT Core and physical ESP32 acting as a thermostat
36 stars 11 forks source link

how do i validate EndpointHealth interface in alexa #11

Closed gladson1990 closed 3 years ago

gladson1990 commented 3 years ago

so far, i have implemented the system which uses the aws iot core connected to esp32 and lambda for skill triggers. It is working fine when a skill triggers a cmd and alexa(lambda) changes the desired state of the shadow in the aws iot core and the esp32 recieves delta process it and updates the reported of the shadow.

The problem is when the esp32 is down or not connected , how do i report that to the user? so far now alexa responds okay for the cmd issued since aws iot core is updated. How do i use the EndpointHealth interface and report an error to the user ? I tried in many places to figure out but couldnt find it.

matwerber1 commented 3 years ago

Hi there. I'm not 100% sure, but I'll walk you through the way I think you would address this.

So first, you have an EndpointHealth interface that you can implement in Lambda. In theory, a request from Alexa would hit this interface and your Lambda would have logic to return an answer as to whether or not your device is online.

The problem is, how does Lambda know the device state? - sure, your device can report status when connected... but let's say your device suddenly spontaneously combusts (or realistically, loses internet connection). Obviously, the device has no way to update the IoT shadow as to whether it's connected or not.

The answer is a "Last Will and Testament" (LWT). This is a feature of the MQTT protocol whereby, when a device first connects to an IoT broker, in this case AWS IoT, it says "if I disconnect from you (the broker) for any reason, I want you to publish the following message on my behalf".

So, as an example, your device could register an LWT message that would publish a disconnect notification, e.g. isConnected = false. LWT's can't update shadow directly, but you could publish to a different custom topic and have a Lambda listen to this topic. When the Lambda receives a message, the Lambda can then publish a message to update the shadow. Finally, your EndpointHealth Lambda handler can read the connection status from the shadow.

Here's some docs on this approach: https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-comms-app.html#thing-connection

Another option is that AWS IoT Core automatically publishes a lifecycle event when a device disconnects. You could also use the rules engine to listen to this automatic event and take appropriate action (e.g. update shadow state):

https://docs.aws.amazon.com/iot/latest/developerguide/life-cycle-events.html

Finally, its possible a device disconnects just for a brief moment, perhaps due to some transient network issue, and them reconnects. In this case, maybe you don't want to take action... maybe you only want to do something if the device is disconnected for more than X seconds. The link above also has a blurb about using SQS delay queues to handle this:

Handling client disconnections The best practice is to always have a wait state implemented for lifecycle events, including Last Will and Testament (LWT) messages. When a disconnect message is received, your code should wait a period of time and verify a device is still offline before taking action. One way to do this is by using SQS Delay Queues. When a client receives a LWT or a lifecycle event, you can enqueue a message (for example, for 5 seconds). When that message becomes available and is processed (by Lambda or another service), you can first check if the device is still offline before taking further action.

Hopefully this helps!

gladson1990 commented 3 years ago

Yes got it ,. and thank you for the prompt response :)