What would be the best way to implement a delay for an SNMP Get operation, when the device needs some time to process a WRITE-only SNMP Set parameter?
Example :
- a ‘Load Presets’ BUTTON. (write only SNMP action)
- the device needs some time to prepare the presets
In this particular case we cannot immediately retrieve the Presets, because the device needs some time to prepare them.
What is the best practice for delaying the SNMP Get operation after having executed the SNMP set action?
Hi Filiep,
I have made a small test connector using the below approach. When checking the stream viewer the delay is done correctly before the GET is executed.
Approach:
- A write parameter with SNMP OID + options=”snmpSet” triggers a QAction.
- This QAction will sleep for 5seconds and force the execution of a trigger (protocol.CheckTrigger method)
System.Threading.Thread.Sleep(5000);
protocol.CheckTrigger(50); - The trigger will execute an action that will run a Group 50 containing the linked params. (execute next)
Note that the options=”snmpSet” will immediately copy the write value into the corresponding read param.
I used the default snmp system contact and system name as test setup.
A timer will run a group 10 with only the contact param. As soon as I write the contact value, the qaction runs and eventually a group 50 is launched to get both the contact and name parameters.
Alternative you can use the next attribute. Important note on this is that the this attribute is applied as a delay between 2 items defined in the <Content> of the component.
For example: A Group (poll action) with 2 action
<Group id=”1″>
<Name>Test</Name>
<Description>Test</Description>
<Type>poll action</Type>
<Content>
<Action next=”5000″>1</Action>
<Action>2</Action>
</Content>
</Group>
The Action 1 will be executed as soon as the group is triggered. Then it will wait 5s before the next item = Action 2 is executed.
This could mean Action 1 needs to be dummy action that does nothing if you simply want to wait X time before something needs to happen when this group is being executed from the protocol Queue.
For your use case this would mean the following approach:
- A write parameter with SNMP OID + options=”snmpSet” triggers a Trigger
- This Trigger runs an action that will run a Group. (the next attribute is not supported on triggers)
- This Group is of type poll action containing 2 actions as described above where the 1st action does nothing. and the 2nd action will run a group that does the polling of the required snmp parameters.
Another option, would be just to have a Trigger (on write param) > Action (sleep with your time) then Action (execute SNMP Group).
Not my area of expertise but recently had a similar situation where we needed to introduce a delay between a SET/GET pair. Once we understood the device behaviour we made use of the next attribute of the Protocol.Groups.Group.Content.Pair and it worked well.
You mention pairs, but that is a serial connection, this protocol is SNMP, however the next attribute does exist beyond pairs as well.
Indeed it was a serial connection…thought it would translate to SNMP also. Like I said not an expert 🙂
Hi Filiep,
In this case, it also depends on a couple of things:
- how long do you need to wait?
- what happens if you don’t wait long enough?
- how “heavy” of an operation is retrieving this data?
Assuming it’s not a very heavy operation, and you will receive “old” data or a timeout will occur, you could also poll this information each minute and not require any additional (and “complex”) logic.
* From test results, in this particular case 1.5 seconds is enough.
* If we don’t wait long enough, we get old information back, but this information is important for the user.
Otherwise I could just leave it as is, because this information is polled at least once per minute.
* The information does not constitute a heavy burden for the device, I believe (1 group with 10 parameters)
1.5s is a very small time to wait. In that case, I would avoid any complex logic and work with a sleep to wait for this short amount of time. This would be easy to implement, and wouldn’t cause a lot of impact as it is only executed when a manual write is executed.
This is my general approach when using time windows.
When the button is pressed you can store the time in a parameter. Then, using a timer-based QAction you can check if a (perhaps user configurable) timespan has been reached since that time and the current time, after which you can either check the trigger to do the get operation, or wait for the next execution of the QAction, and check again.
Depending on how strict you want the time to be you will need a fast or a really fast timer. e.g. if your minimum timespan is 30 seconds, but the timer for the QAction is also 30 seconds, you have a worst case scenario of it taking close to 60 seconds. A 5 second timer would reduce it to maximum of 35 seconds.
The second solution is indeed as we implemented it.
The first solution for some reason did not work, I would gladly retest it, but the device was not supposed to be available for doing sets anymore, and a simulation is not entirely reliable for this.