Why are 0x10d30 events always created at the same time as 0x10d35 events?

Document ID : KB000011897
Last Modified Date : 14/02/2018
Show Technical Document Details

This is a techdoc to explain the behavior why Spectrum will always generate a 0x10d30, (an event that clears loss of contact) on a device model, before Spectrum asserts a 0x10d35 event (Device has stopped responding to polls).


Why are 0x10d30 events (The condition that causes the loss of contact on the device model has cleared) always created at the same time as 0x10d35? (Devices has stopped responding to polls).  I have noticed that right before a 0x10d35 event is created and at the very same second a 0x10d30 event is created.  What is the reason for this?


Whenever the contact status of a device changes, Spectrum will automatically generate a 0x10d30 event in order to clear any existing alarms (gray/blue/red) on the device before generating a 0x10d35 event.

In this case, when device contact status is lost, Spectrum generates a clear event (0x10d30) to clear any existing alarms such as Initial (blue) or suppressed (Gray) alarms, before asserting a new 0x10d35 event that will create a critical (Red) alarm.


That is the reason why first a 0x10d30 event is generated (to clear existing alarms) before asserting a contact lost event (0x10d35), this is done at the very same second.  This is FAD (functioning as designed) and is not a bug but is normal behavior.