Hi Everyone.
When using various Protocols on a daily basis, it is difficult to know when each parameter is being polled.
Some protocols have parameters that are not polled until one hour has passed since the last poll.
This is very inconvenient for operators who cannot see the Dataminer logs in detail.
Is it possible to list the polling cycle for each parameter ID somewhere?
Just stating the last polling time would be helpful.
*I understand that some very limited protocol parameters are made that way.
Of course I know that there is a Timebase.
But this value is only a relative multiplier and does not indicate the absolute value of time.
I would like the Dataminer software to record the polling time on the Dataminer software side, independent of the protocol.
It would be very easy to use if we could go one step further and modify the polling cycle for each specific parameter for each element above a certain authority.
Hi,
Unfortunately, what you are looking for is currently not available within DataMiner.
Parameters tend to be part of a polling group sometimes with multiple parameters and groups tend to be added to timers, also each with multiple groups. So, retrieving each individual parameter polling cycle would technically be possible, controlling it not so much due to the dependency/linking I mentioned.
For the “visualization” part, although we do not have the last polling time, there is the “last change time” when you double click a parameter, which can already be of some use (see screenshot below)
For the “control” part we currently only have the Timer Base.
As you mention, there is Timer Base but that is linked to the timers so indeed it would be a multiplication factor but for all parameters at once.
We do have some connectors that support that the operator assigns which timer to be used for certain functions but this is not the common practice and when implemented is typically a choice between a Fast, Medium and Slow timer.
If you see that it would be of value to have such features in DataMiner, feel free to add a new item on DataMiner Feature Suggestions with your use case and we will certainly evaluate it.
I’ve already added a Feature Request as per your suggestion, to see if we can get this on the roadmap at some time. Might be something for which we can come up with a reasonably simple solution.
Thank you.
This function is always a question that comes up frequently when demonstrating to users.
If implemented in some way, it would be very helpful in promoting Dataminer.
To add to what João’s answer, the polling times are very different between protocols because they also depend on the capabilities of the devices. Usually, important and highly dynamic parameters are polled quite often, while setting parameters are polled very infrequently. I do understand that this is not really visible to an operator though.
But that being said, we are seeing more devices which are event based rather than rely on being polled, which takes away the delay concern. This behaviour may be something we want to take into account when refining the feature request added by Ben.
In the Protocols folder of a DataMiner agent, next to a specific Protocol.xml, you should already find a file named Polling.xml which will contain a list of all parameters and their polling interval that DataMiner could find out after some basic processing of the timers in the protocol.
More advanced analysis like a parameter set through a QAction which fires e.g. every 1 minute is currently not supported yet.
Below you can find an example of how the content of this file looks like:
<?xml version=”1.0″ encoding=”utf-8″?>
<Protocol>
<Params>
<Param id=”1″ pollingInterval=”60000″ />
<Param id=”2″ pollingInterval=”120000″ />
</Params>
</Protocol>
The pollingInterval attribute is specified in milliseconds.
As far as I’m aware, this information is currently only used in the alarm template editor of DataMiner Cube. More specifically to give a warning to the user when alarm hysteresis is configured on a parameter with a time that is lower than the polling interval of that parameter.
This is described in Configuring alarm hysteresis in an alarm template.
It might be valuable to bring the information that is already available today more to the foreground in the DataMiner clients, e.g. below the last change property per parameter.
Only administrators or users with similar privileges can view the file.
We need a system that can be viewed by operators who do not have more knowledge of XML.
Hi Yuki,
You can use the ‘Last change’ property that’s available when you drill down to one parameter in specific (double-click in the parameter).
This will show you the last time this parameter was updated, which should match with the last time it was polled.
Bruno – I believe this indicates when the value of the parameter changed for the last time, not when it was polled (if a poll occurs, and the value of the parameter is the same as when it was polled previously, then this time stamp is not updated)
Yes, if there is a Last Polling:dd-mm-yy here, my hope will be fulfilled.
I believe it is a legitimate question from a user perspective. Not an easy one, for the reasons you outlined (the complex relation between polling commando’s and the parameters that eventually through some logic emerge from those). But maybe there are some ways to check how often a parameter gets an update (which would be different than the change that we track now).