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

Managing IoT Core Jobs with Greengrass v2

0

Hey

I have custom Greengrass component (python) which manages IoT Core jobs by subscribing to $aws/things/MyThing/jobs/notify-next topic with GreengrassCoreIPCClientV2 client (https://github.com/aws/aws-iot-device-sdk-python-v2/blob/main/awsiot/greengrasscoreipc/clientv2.py). So basically when a new job is created and it's received a message, it handle a job execution. Even when the device's internet connection is interrupted after reconnecting it still gets a message because of the same persisted session in the MQTT connection which is handled under the hood of ipc client (https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html#mqtt-persistent-sessions).

I want to cover the case where any new job message is sent when my component is running, the device is disconnected from the internet and it reconnected after my session was terminated (by default after 1 hr, but could be extended to 7 days) and I didn't receive a message about the next job because of it. In this case, I should query available jobs in the queue, take the first one and handle it. But, from where I can get any indicator that my connection was lost or I'm reconnecting with the clean session to know a time when I need to query that?

In LifecycleHandler class (https://github.com/aws/aws-iot-device-sdk-python-v2/blob/6cdd7c5f7ad8d11b998e37a9c397d3cd21a6f063/awsiot/eventstreamrpc.py#L90) which I can pass as an argument to connect function of ipc client have on_disconnect function but it's invoked only with executing close function on that connection so it's not the case. Can I access any parameter of ipc client that could give me information about connection? I see that specific logs about connection are logged in greengrass.log. Maybe nucleus itself can emit some event/message about connection which I can capture with my custom component. I know that there are messages on $aws/events/presence/+/clientId topic but that gives me information on cloud side and I want to avoid creating additional IoT Core Rules to handle it and send it back to the edge device with this information. Or maybe there is another way to manage IoT Core Jobs from Greengrass perspective?

Topics
Internet of Things (IoT)ServerlessCompute
Tags
AWS IoT GreengrassAWS IoT CoreInternet of Things (IoT)Job Scheduling
Language
English
Grzegorz
asked 7 months ago490 views
2 Answers
0

Hello Grzegorz,

Greengrass IPC does not provide any method to know if the MQTT connection to IoT Core is disconnected or not. What you can do is to occasionally send the MQTT message to get Jobs: https://docs.aws.amazon.com/iot/latest/developerguide/jobs-mqtt-api.html#:~:text=GetPendingJobExecutions. This way, your component can receive the job when the connection is eventually available.

Cheers,

Michael

AWS
EXPERT
MichaelDombrowski-AWS
answered 7 months ago
  • Grzegorz
    7 months ago

    That's a shame tbh. AWS provides a component for shadow state managing and it works brilliantly. Even after reconnecting with a clean session, it's still synchronizing with the cloud on realTime settings and sending message on the local MQTT topic to inform other components, maybe AWS should think about a similar solution for jobs handling? Anyway, in the meantime I developed a workaround solution for this case. For anybody from the future, you can check it here https://github.com/zdb11/Greengrass-Jobs-Handler

  • MichaelDombrowski-AWS EXPERT
    7 months ago

    Thank you for your link. Knowing the MQTT connection state is something that has been requested before, so I'll see if we can implement that in the future. Greengrass was designed with the idea that components shouldn't really need to care about the state since published messages are queued and sent later when offline, but there are definitely reasons why a component would like to know the true state.

-1

Hi:

Thanks for the detailed use case walkthrough. Can u help me understand the statement that you made - client have on_disconnect function but it's invoked only with executing close function on that connection so it's not the case? Does that mean you will call the close() function as part of your use case logic? If that is the case, I think we have the reason: Optional[Exception] as an optional param that you can take advantage. Like when you are calling close() function it is None, and on the other hand you can identify the type of exception of the the MQTT disconnection and conditionally do your own data query logic in the method.

Rafe

AWS-GG-Rafe
answered 7 months ago
  • Grzegorz
    7 months ago

    Hi No, I will no call it because I don't have reasons to close my connection. I want my connection to be opened all the time and callback on every message on that topic. If on_disconnect function could execute itself on connection interrupted that will be perfect but I don't know how exactly could I implement that because as far as I know it get invoked only after executing close function on connection.

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