AxedaPollingStrategy Thing
The AxedaPollingStrategy Thing requires Execute permissions to the ReportingAlgorithm and GetConfigurationTable services This Thing defines an Axeda polling-based strategy that is used to determine if a device is reporting. It is derived from the ReportingStrategy Thing Template provided in the ACE. The two properties that the ReportingAlgorithm evaluates are set in the AxedaPollingStrategy Thing Shape (additionalMissedTimeAllowed) and the Thing itself (acceptableMissedPings, which is derived from the Axeda.Asset Thing Shape).
What is the Axeda Reporting Strategy?
The Axeda reporting strategy is a strategy for polling devices that specifies how the Thing Presence algorithm should determine whether Axeda polling devices are online and communicating with the ThingWorx Platform. Provided as the AxedaPollingStrategy Thing, this strategy is applied by the ReportingAlgorithm to all Things representing Axeda's eMessage Agent devices.
In a UI for monitoring Axeda eMessage Agent devices, end users will seldom find the isConnected property set to true, and even then, it is only for a split second. This behavior is considered normal for polling devices. End users who are monitoring polling devices should rely instead on the isReporting property, which is set to true if the ReportingAlgorithm determines that the polling device is online.
The AxedaPollingStrategy Thing provides some customization options to allow you to configure the strategy to your needs. Such customization options include properties that allow you to:
• Set the number of missed pings allowed before determining that a device is no longer reporting. The property name is acceptableMissedPings. This property is set for each asset (Thing) and described in the topic, Axeda.Asset Thing Shape.
• Set an amount of time (in milliseconds) that a device can miss pings before determining that it is no longer reporting. The property name is additionalMissedTimeAllowed.
These configuration settings can be used independently or in combination to create a unique case for various devices. For example:
|
If Acceptable Missed Pings is set to
|
And Additional Missed Time (ms) is set to
|
Then
|
|---|---|---|
|
0
|
0
|
Zero missed pings and zero additional missed time mean that you expect the device to never miss a ping. The ReportingAlgorithm considers the device as not reporting as soon as the device misses a ping.
|
|
0
|
7200000
|
Zero missed pings and two hours of additional missed time mean that you do not expect the device to miss a ping and that the ReportingAlgorithm should wait two hours before considering the device as not reporting.
|
|
5
|
0
|
Five missed pings and zero additional missed time mean that a device is still reporting until it misses more than five pings. The ReportingAlgorithm considers the device as not reporting as soon as the device misses the sixth ping.
|
|
4
|
3600000
|
Four missed pings and 60 minutes of additional missed time mean that a device is still reporting until it misses four pings plus an hour of additional time. The ReportingAlgorithm considers the device as not reporting as soon as it has missed four pings and an hour has passed since the last missed ping.
|
When trying to determine what will happen if the device pings late, you need to consider the ping rate. If the ping rate is every 100,000ms and you can accept two missed pings plus 60,000ms, then reporting will go to false once there is no ping for 260 seconds.
The system does not track how late the last ping was unless it is late enough that the number of missed pings allowed is exceeded AND the additional time has elapsed, which would cause the ReportingAlgorithm to change isReporting to false.
 |
If the acceptableMissedPings property is set to zero and a ping is received even milliseconds after it is expected, the ReportingAlgorithm may identify the device as not reporting. If you encounter this situation when using this property, consider adding some small amount of time to the additionalMissedTimeAllowed property to allow for some minor fluctuation in the execution of the evaluation. For example, setting the additionalMissedTimeAllowed property to one second (1000ms) and the acceptableMissedPings property to 2 will allow a ping to occur up to one second later than expected while still allowing the device to be identified as reporting. Similarly, if the number of missed pings is 5 and you expect network fluctuations, consider setting the additional missed time allowed to at least one second.
|
Reporting Evaluation
For all Axeda eMessage Agent devices, reporting evaluation occurs:
• When the device contacts the ThingWorx Platform, more specifically on bind events, in which case a device is considered reporting. If a BindingEvent is triggered, the device is considered to be reporting, even if it is an unbind request.
• On a timed interval with a default of evaluating once every five minutes, in which case a device may be considered not reporting if it fails to meet the missed pings and missed time criteria. The AxedaPollingTimer Thing detects devices that have been disconnected for too long. To change the value of the timed interval, go to the AxedaPollingTimer Thing and, under Configuration, adjust the updateRate.
The value of the isReporting property for a Thing is changed by the result of the ReportingAlgorithm evaluation. Evaluations and subsequent changes to the isReporting property occur when the AxedaPollingTimer runs to re-evaluate the reporting status of a device.
Upon evaluation, if the number of missed pings is greater than the configured number of allowed missed pings, the following error message is logged:
Invalid AcceptableMissedPings Configuration Value " + acceptableMissedPings + " Thing: " + source
If the device has exceeded the configured missed time allowed, the following error message is logged:
Invalid AdditionalMissedTimeAllowed Configuration Value: " + missedTimeAllowed + " Thing: " + source