When implementing a connector, you have the option to link the visibility of a page to a parameter value.
https://docs.dataminer.services/develop/schemadoc/Protocol/Protocol.Display.Pages.Page.html
But what about parameters on non-visible pages that are enabled for monitoring?
DataMiner Element Alarm Severity
The element's alarm severity will be the highest alarm severity over all the parameters (even the ones that are currently not visible)
- Is this implementation actually correct?
- What if the element indicates a certain alarm severity, but the operator cannot see the parameter(s) with that severity?
Alarm Console's Active Alarms
The alarm console's active alarms will show all the alarms of the element (even for the parameters that are currently not visible)
- Is this actually desired?
- The operator won't be able to find the specific parameters on the elements as the pages aren't being shown. This is kind of a 'sticky' alarm implementation.
DataMiner Software Feature
Should the DataMiner software be updated to (not) take the alarming of non-visible parameters into account? Maybe this should be a configurable option so those alarms are (not) ignored in case the parameters aren't shown?
Currently there's the option to conditionally alarm parameters via the alarm templates.
But is this the ultimate convenience in case of conditional paging?
https://docs.dataminer.services/user-guide/Basic_Functionality/Protocols_and_templates/Alarm_templates/Configuring_alarm_templates.html#using-conditions-in-an-alarm-template
Connector Implementation
Should we consider implementing the conditional monitoring in the connector itself when having conditional paging? This being part of the ultimate convenience.
https://docs.dataminer.services/develop/devguide/Connector/MonitoringAlarming.html#conditional-parameter-alarming
Hi Brecht,
This feature (page visibility linked to parameter value) originates from the use case where certain pages did not contain data because polling was conditionally disabled for the parameter on those pages. The feature allowed to hide these 'not initialized' pages.
Reading your question, I assume you want to use this feature for other scenario's? Would it be possible to share your use cases for using this 'page visibility linked to parameter value' feature please? So basically, why do you want to hide pages in your connector?
Hi Pieter,
The pages are linked to a device’s functionality.
I.e. it can only be an encoder or a decoder.
Therefore, the pages, and by such the parameters, are no longer displayed for the unused functionality.
The alarms for parameters on non-displayed pages are however still shown and taken into account for the element’s severity, etc.
With the new dev guideline where we would clear the alarms for such related parameters, we no longer have these ‘sticky’ alarms.
In most cases, the visibility of pages won't change very often so as a user, I would also expect you will not add alarming on these parameters as you are not interested in them anyway?
Short term, we can definitely work with the conditional alarming.
Long term, I would like to see it configurable if the alarm should be shown/thrown or not. In addition it could also be nice that if the alarm is shown for a ‘hidden’ parameter, that this would be seen in the alarm console via an icon or extra text somewhere.
Of course, this is also a topic that goes into a lot of other modules like correlation, etc.