Each thing-definition comes with some predefined metrics that are automatically handled by Servitly.
Cloud Status
Identifies the thing activation status that is used to determine if a Thing can communicate with the cloud or not. A new status is automatically registered within the Cloud Status metric each time the cloud status changes, for instance, the thing has been activated or deactivated.
Note that the cloud status metric is only used to access historical status values, while the actual status is the one saved on the object as a property.
The metric is of integer type, and each value returned corresponds to a precise status.
| Value | Meaning | Description |
| 0 | INACTIVE | Incoming IoT data is discarded, events and other periodic computations are stopped. |
| 1 | TEST |
Like ACTIVE but with a disclaimer in the dashboard. |
| 2 | ACTIVE | The thing can publish data, and it is counted in the billing. |
| 3 | This status is deprecated and no longer used. | |
| 4 | PROVISIONING | The thing initial status when created. When done, the status is automatically changed to ACTIVE. |
| 5 | ACTIVATING | The thing is about to be activated. When done, the status is automatically changed to ACTIVE. |
| 6 | ACTIVATING_TEST | The thing is about to be tested. When done, the status is automatically changed to TEST. |
PROVISIONING, ACTIVATING and ACTIVATING_TEST are transient statuses and, for this reason, not saved in the cloud status history.
Connection Status
This metric indicates whether an object is ONLINE or OFFLINE.
The metric is of integer type, and each value returned corresponds to a precise status.
| Value | Meaning |
| -1 | UNREACHABLE |
| 0 | OFFLINE |
| 1 | ONLINE |
The status of the connection is updated automatically by Servitly, but by going into the connection status metrics edit page (available in each thing-definition), you can change how the status is kept up-to-date.
Timeout
The time after that the thing is put in OFFLINE status if no more values have been sent by the thing. For instance, if a 2 hours timeout has been configured, the thing goes OFFLINE only 2 hours after the last received value. Take care to configure a timeout, which is in line with the urgency in detecting whether the object is connected or not.
LWT
With the Last Will and Testament feature of the MQTT protocol, it is possible to detect in real-time if a thing disconnects from the cloud. The LWT requires that, during the MQTT channel establishment, the thing publishes to a specific topic the WILL message. Generally this is done by the client, so it is enough to specify the LWT topic and message.
TOPIC: <PATH_PREFIX>/<USERNAME>/<ASSET_ID>/<LWT_PATH>
{
"will": true
}
Other than the Path, you need also to specify the Path Prefix, which depends on the underlying MQTT broker:
| IoT Connector | LWT Path Prefix |
| Servitly Thing Connector | STC |
| Everyware Device Cloud | $EDC |
Once the LWT is configured, in case the thing loses the cloud connection, the MQTT broker resends to the subscribers the WILL message notifying that the thing is OFFLINE.
Note that, the WILL message is sent to the subscribers only after one and a half keep alive periods has passed. For instance, if the keep-alive interval is 5 minutes, the WILL message is notified only 7:30 minutes after the thing has sent the last message (measure, keep-alive ping). So be careful to set the right connection keep-alive interval if you want a real-time (or near real-time) connection status update. It is suggested to avoid periodically sending the keep-alive PING even if the thing is publishing measures, generally, this is automatically handled by the MQTT library.
Optionally, if you are using Everyware Device Cloud, you can specify the Birth path, that allows collecting birth information sent when the thing connects to the cloud. The birth certificate can be used to send connectivity information (e.g. SIM ICCID, signal level).
Comments
0 comments
Please sign in to leave a comment.