Failure to monitor connection status of local client devices from IoT Core


I'm considering to monitor the connection status of all Greengrass core and client devices from the Fleet Hub. When interacting with local client devices, Fleet indexing never updates the connection state of the client device. I ran the sample Greengrass discovery application from the "Connect and test client devices" tutorial ( I was able to subscribe messages from client device by using MQTT test client, but connection status has been never updated. The connection state was updated when publishing directly to an IoT Core service endpoint from the client device. Can MQTT bridge component relay lifecycle events?

asked 8 months ago85 views
1 Answer
Accepted Answer


Today Fleet Hub and Fleet Indexing connectivity (FI) will only report for MQTT connections directly to AWS IoT Core. You should be able to see the Greengrass Core device connectivity status but will not be able to see the status of client devices that connect to the local MQTT broker. The reason for this is that FI uses the lifecycle events from IoT Core. There isn't a way for a Greengrass Core device to emit those events for client devices.

You could create a component that reads the Nucleus log file, greengrass.log, and parse client device connect/disconnect events. Fleet Hub will not be able to report on those from a connectivity perspective, but you could update a custom attribute or shadow field with device status and then create a Fleet Hub query.

To track interest, please consider creating an issue for the Greengrass team to track a feature request.

Please let me know if this helps, or if you have additional questions!

answered 8 months ago
  • Thanks for your response. I now have a better understanding. Thanks for the detailed explanation. It might be better to allow client devices to make MQTT connections directly to AWS IoT Core. I've raised an issue ( on github.

  • Client devices can connect directly to IoT Core if their is a policy associated with the certificate and there is a network path. Local connectivity to Greengrass can reduce latency and allow for local communication when connectivity to the cloud isn't available. One pattern may be to have local devices connect to IoT Core with Greengrass as an alternative, or two have two connections (one to IoT Core and one to Greengrass). Endless possibilities! :)

  • I'll try to do it in a way that has two connections. Thanks again!

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