We have registered a device via LoriotAgent on Cumulocity. After the registration we set the “Required interval” on the device. After the setting the “Required Interval” 3 new properties (fragments) are created on the device (managed object):
The device works as expected, we receive data from the device and we can send configuration to the device.
If the device is now deactivated by an user and no longer sends data at the specified interval, the value c8y_Availability.status is set to UNAVAILABLE. At some point, the value c8y_Connection.status is also set to DISCONNECTED.
When the device is switched on again and sends data in the interval, the value c8y_Availability.status is set to AVAILABLE again. However, the value c8y_Connection.status remains DISCONNECTED and from then on it is no longer possible to send configuration to the device.
I have tried so many things to get the device back to c8y_Connection.status CONNECTED. However, the only thing that worked to restore the downlink function was to delete the device and create it again. But this is not a solution.
My Questions:
How does connectivity work?
Is there any relation at all between the DISCONNECTED status and the loss of downlink functionality?
Which service is responsible for the value c8y_Connection.status?
Why is the c8y_Connection not set to CONNECTED, although the device sends again in the interval?
Do you know a workaround to restore the device to CONNECTED status?
Monitoring of send connection and push connection is generic platform functionality that is available for all devices. It is documented here: Cumulocity documentation - Connection monitoring. The functionality is independent of the way that your devices communicate with Cumulocity. Send connection becomes green when there was data received within your configured interval. Push connection is green when there is an active MQTT or realtime connection for the device.
If connection status for your devices is reported as “DISCONNECTED” then that is an indicator of the problem you are experiencing with reaching your devices with downlink. Loriot microservice in versions before 2.0.0 depends on realtime connections to receive the created operations from Cumulocity. If this realtime connection is not present the operation is never received by the microservice and the command is never forwarded to the Loriot API.
We know that Loriot microservice had an issue with reliably keeping these realtime connections up in some environments. This is why this mechanism changes with version 2.0.0. From then on we no longer rely on realtime connections. This means that push connection monitoring will no longer work for Loriot connected devices but downlink operations are reliably handled again.
There are ways to affect the push connection status of your device, however none of them will solve the problem that the created downlink operations are not forwarded to Loriot and ultimately your device. The push connection status is only the symptom, not the cause.
Thank you for the reply and the detailed answer. If I understand correctly, after Loriot Agent version 2.0.0, the push connection monitoring for Loriot devices is always disconnected (the gray icon). But this has no impact on the function of the downlink, because as long as the Loriot server is available, the downlink works, right?
Will the Loriot agent update have any effect on the existing devices?
The Loriot agent update will have no impact on the functionality of the API function /devicecontrol/operations, right?
When is the release of Loriot Agent 2.0.0 planned for?
PS: We are also willing to test a pre-release version of the agent .
Functionally these changes are intended to be entirely transparent. We are only changing how Loriot microservice obtains the operations from Cumulocity. Both the creation of the operations as well as the processing remain unchanged. Any interactions you may have with /devicecontrol/operations API to create or read operations for these devices can expect the same behaviour.
Unless we run into significant last-minute trouble I expect that rollout to production environments will start within the next 1-2 weeks. Since you are on a public cloud environment, we currently cannot provide pre-release versions because this would also affect all other users on the environment.
.