Hello,
I managed to set up a Dataminer system and now i am working on the alarming side. My device is AppearTV XC5100.
When i create a bad input on the XC5100 unit, i get a critical alarm raised as soon as the unit fails to receive anything. Assuming this happens at 11:00:00 and the alarm is displayed in the web interface of the unit, my Dataminer does not alarm at 11:00:00 or 11:00:05 (assuming there is a delay). It takes like 1-2 minutes until Dataminer is aware of the alarm.
Is there a setting that i could make so the alarms are sent instantly (or at least with a low delay (seconds maybe)) to Active alarm list or to me via email?
The exact same thing applies when the alarm is no longer active. In the web interface disappears quite fast but in Dataminer it takes another 1-2 minutes to be cleared.
There is no hysteresis set on the alarming side of the Dataminer. I created a filter where all Critical Alarms are being sent via email so the unit is monitored for any critical alarms.
Am i doing something wrong?
Thanks!
1st time: i check the web interface of the unit – alarm is set
2nd time: i check the Alarm tab from the XC5100 element. This tab gets the information from the web interface of the unit. Most of the times, i am able to see an alarm here but it is only informative as long as Dataminer is not set to pursue that kind of alarm.
3rd time: i check the Alarm tab of Dataminer’s Element. Here alarms are present only if the alarm template has been set.
In my case, i have set the parameters to be monitored and applied the template.
And to answer to your last question:
Parameter is not updating quick enough in Dataminer and the alarm state of the elemtn is not changing in time.
The only thing is that the alarms are being displayed slow in Dataminer.
I assume this is based on polled data, i.e. we get an update of the value of that specific metric each x seconds/minutes, and it is only when that new value is coming in and being compared to the threshold defined in DataMiner that DataMiner will create an alarm in DataMiner for that.
Normally, if polled data is used, we try to design the driver so that the most critical data (used to monitor the device) is fetched at regular intervals, so that the delay is kept to a minimum.
FYI – something you can try to determine this, is to increase the polling speed on your test element by changing the value of the Timer Base to 0.5. Then you should see double speed. https://docs.dataminer.services/user-guide/Basic_Functionality/Elements/Working_with_elements/Changing_the_polling_speed_of_an_element.html
Hi Ben,
I have seen your guides, including the one about the Alarms. In that one, when you create an alarm to be displayed or sent by email, you get a quick reply.
When you increase the parameter value, you get feedback in a few seconds. Then, you get email notification as well.
In my case, i generate the alarm by altering an input. Then Dataminer waits 1-2 minute until finds out about this alarm. I am trying to understand if this is desired or i messed something up.
Any feedback is greatly appreciated.
Thank you!
If you mean that you increase the parameter value through DataMiner, and you trigger a DataMiner alarm on that value, then indeed things would go quick. Because if you change a setting through DataMiner, then typically the polling prioritizes first the fetching of that specific parameter from the target device. So that value of that metric would almost immediately update, and if it is above a threshold defined in DataMiner, then the associated alarm would also be generated almost instantly.
If you however alter an input (something you do on the device level), then this altered input will be reflected in some parameters in the device that will change (e.g. INPUT STATUS = no signal). DataMiner fetches all the data from the device in cycles if it is based on polling. So DataMiner would only be aware of the new value of the metric after some time, and then compare that value to the threshold defined in DataMiner, and generate an alarm if needed.
Very likely you did not mess up anything. While it is hard to judge based on the information available, and the way I interpret what you are saying, it might be a case of polling intervals (which could be confirmed / debunked by changing that Timer Base on your element to 0.5 or 0.25 for example). And if this is the problem, we might have to take a look at the driver to see if it uses properly defined polling cycles (and whether or not that device provides maybe also unsolicited options to get updates instead, instead of having to poll data).
Could you share where you are observing the alarm? Is the parameter not updating quick enough, is the alarm state of the element not changing in time…?