On element startup, if it does not get any response from the device, say the device is powered off, is there a way to ensure that once communications is achieved that the protocol starts polling from scratch with all timers reset to ensure all groups are polled. For example, if there is parameter that is only polled every 6 hours and upon element startup the device was offline, then when the element initially attempted to poll this parameter it timed out but then a few minutes later the device came online. In this case I would want the protocol to reset all the timers to ensure all parameters are polled at least once. Another way to look at is that the element does not start any polling timers or buffering up polling commands until communications to the device has been achieved. I hope this is clear.
Thanks
The slow poll that Jarno suggests will only partially provide a solution. It will indeed prevent the other communication from happening but there is one drawback in the way the slow poll is working:
If timers are supposed to be active when the slow poll is active then the groups will be added to some kind of waiting queue to be executed when the element goes out of timeout. However for timers that didn't go off during the slow poll then those groups will not be present on that queue.
To summarize:
At startup of the element, the slow poll will not be active. That will only be active after x configured seconds after the device went into timeout.
If there is a 6 hours timer and the groups were added to be executed just before the slow poll period then these won't be executed.
-If the device is communicating after 1 hour, then the 6 hour groups will not be executed as that timer did not go off yet.
-If the device is communicating after 7 hours, then the 6 hour groups will be executed as soon as the device communicated as the timer did go off during the slow poll period.
What would be needed to reach the required behavior is the slow poll functionality and a driver modification to trigger on the content of the ping group. If the content gets filled in (and this is never gets filled in by normal polling) then it means there was a slow poll active and communication is good again. Based on that trigger, execute an action to restart all timers and have the reschedule set to true so their timer content is immediately executed again.
Hi Jeff, I believe the particular feature of interest is Slowpoll for you. A similar question has been asked (How does slow poll work? - DataMiner Dojo). Perhaps the answer is what you're searching for?
An extract from the DataMiner Help:
When an element is in a timeout state, the DMA can force it to go into so-called slow poll mode. While the element is in that special poll mode, the DMA will not send any commands to the element. Instead, it will just send a protocol-dependent ping command at regular intervals. As soon as the element responds to that ping command, the DMA will start polling the element the normal way again.
When making the implementation yourself, it is important to configure the ping group correctly as explained on Protocol thread run-time errors: use cases - DataMiner Dojo