This is a snippet of the logs from an adva element that has a repeated logs following the same pattern of the Element Alarmstate flipping from critical to clear. Is this problem something someone has seen before and can an element restart potentially fix this.
2025/04/07 00:11:16.825|SLElement.exe|14764|CElement::NotifyAlarmState|DBG|0|** Element Alarmstate changed to 7.
2025/04/07 00:11:23.090|SLElement.exe|13564|CElement::NotifyAlarmState|DBG|0|** Element Alarmstate changed to 0.
2025/04/19 00:11:17.247|SLElement.exe|1212|CElement::NotifyAlarmState|DBG|0|** Element Alarmstate changed to 7.
2025/04/19 00:11:36.048|SLElement.exe|30308|CElement::NotifyAlarmState|DBG|0|** Element Alarmstate changed to 0.
**********
Also, I believe alarmstate 7 means timeout and not critical severity. Back to 0 means the element is polling, but not monitored using an alarm template. Can you double check if the element is in timeout ?
Hi Curtis,
As Arunkrishna commented, Alarmstate 7 corresponds to Timeout state and 0 corresponds to Not Monitored (reference: DataMiner element control protocol | DataMiner Docs > search for 65008).
If you see those logs with such frequency, it could be that the element is having issues connecting to the device or that the device is not replying to some of the requests but is replying to others.
You could start by checking the Stream Viewer and confirm what is the communication state.
Based on the information you collect from Stream Viewer you can determine if that particular device is just a bit slower than expected, in which case you could increase the Timeout of a single command setting in the element wizard.
Or if it is just a particular command that fails, you could then check if it is expected or if something may need to be configured at the device level.
Hi Curtis, normally you should also see alarms in the alarm console in Cube around that time. They should contain more information about why the alarm was raised. Have you already tried to retrieve them?