We have an SNMP based protocol that has a table, call it table 1, were the data from the device for 2 of the columns is not very accurate but there is different table, call it table 2, that contains more accurate values that I would like to use. I am wondering if there is an acceptable way to have the protocol stop using these 2 values returned in the device’s SNMP response for table 1 and instead use the values returned in the SNMP response for the table 2. Table 1 is used throughout the system in custom dashboards and like items so I do not want to restructure all the graphics so this seems like it would be an easy way to address this issue. The 2 table are not based on the same index but they are related. Table 1’s index is an IP address and table 2 has a column for the IP address. Thanks in advance for any advice.
Hi Jeff,
If I understand your question correct then you want to replace the values of 2 snmp columns by other values and these should stay the same parameters because of them being used in dashboards, etc.
If these columns are in the middle of the other snmp columns then these cannot be easily be replaced by custom ones, as polling would not work correct anymore.
I would suggest to add a hidden snmp table that polls all the values for table1. Change the existing table1 into columns of type “retrieved” instead of snmp and copy over the values from the hidden snmp table and snmp table2 into the existing table1 (via qaction that triggers on changes of the snmp tables). This way it will be backwards compatible with the dashboards.
If there would be no dashboard compatibility problem then the suggestion would be to remove the 2 faulthy snmp columns from table1 and add 2 retrieved columns at the end where the values of table2 would be copied into.
Regards,
Only changing those 2 columns is not possible. It will break normal polling for the table. What Laurens is suggesting is to make is
1) Create a new table3 and copy all SNMP columns that you want to keep from the original table1 (all columns except the two you want to change).
2) Change all columns in table1 to ‘retrieved’. This will not impact the dashboard behaviour.
3) QAction logic from table3: Copy all SNMP data to the corresponding retrieved columns in table1.
4) QAction logic from table2: Fill the two mentioned columns in table1, just as you were already suggesting.
That is correct how Robin is summarizing it. A possible alternative to avoid the creation of the volatile hidden snmp table3 could also be to poll the snmp values directly from a QAction via an NT_SNMP_GET NotifyProtocol call and fill in the result directly in table1 (with the retrieved columns), but the downside then is that these results are not visible in the StreamViewer when trying to debug communication, nor will it be taken into account for placing the element automatically in/out of timeout state.
Thanks for all the info people, much appreciated.
Hi Jeff, I’m glad to hear that the info could help. If the provided answer is sufficient, would it be possible to click on the check mark beneath the upvote/downvote icons (has the tooltip “Select this answer as best.”)? This way the question will be marked as solved
Thanks for your response Laurens. The 2 columns from table 1 are indeed in the middle of the rest of the colums in that table (their OIDs are NOT the first or last OIDs in the SNMP table). So if I understand you correctly, there is no way to say simpy change the 2 columns in table 1 from SNMP type to retrieved so that DM does not include them in the GET/GET NEXT SNMP polling logic and then have them get populated from the SNMP polling response for table 2 via some sort of quick action logic? Thanks again.