I have the dude graphing rf power levels and when the module is down it is still creating a graph based on the last reading. What am doing wrong? Heres an example of a Canopy module (I know I know), but we use both.

I have it setup as a Function with the following commands. I multiple it by -1 because the rf power level pulled is a negative number and dude won't graph it otherwise. But right now I have a link that is down and we are still graphing a -62 power level.

AVAILABLE
("iso.org.dod.internet.private.enterprises.mot.whispRoot.whispProducts.whispSm.whispSmStatus.radioDbmInt.0")

ERROR
if((oid("iso.org.dod.internet.private.enterprises.mot.whispRoot.whispProducts.whispSm.whispSmStatus.radioDbmInt.0")), "","failed")

VALUE
oid("iso.org.dod.internet.private.enterprises.mot.whispRoot.whispProducts.whispSm.whispSmStatus.radioDbmInt.0")* -1

Maybe the available or error conditions are always true so the probe is never actually down.

Lebowski

I still can't figure this out. The wiki is worthless or perhaps I just can't follow the instructions. It says not to use the OID in the available line, but yet if I don't it graphs nothing. I still don't understand what available is for. I also don't understand how it can report the probe as being down but still graph a power level. Today I tried a test with the above code, I shut down the slave link, rebooted the master to clear any record of the slave ever being registered to it, and dude was still graphing a -60 power level while they were not linked together.

How in universe is that possible?

The available line is used to test to see if the Probe can be installed on that device type. Most the time people put -1 in the available line for false but it is in fact not false which makes the probe function incorrectly. Make sure the logic on your available line works correctly. Place the code of your available line in the appearance of your device so that you can see how the logic is working.

Lebowski


EDIT use a function in the available line not the OID directly, yes I agree.

Use a function to determine the value or false, then in the available line determine if the value is not false then in the error line make sure it is not false and is a valid value or generate the false or error message. Graph the value if true... This graphs negative numbers just fine but you can multiply if you like.

Here is a Cisco RSSI function. This returns a value or false.
NAME: Wireless_RSSI_a()
CODE: if(array_size(oid_column("1.3.6.1.4.1.9.9.273.1.3.1.1.3", 10 ,5)), oid_column("1.3.6.1.4.1.9.9.273.1.3.1.1.3", 10, 5) ,"False")

Here is a cisco RSSI probe
NAME: rssiCisco
AVAILABLE: Wireless_RSSI_a()<>"False"
ERROR: if(Wireless_RSSI_a()<>"False", if(Wireless_RSSI_a(),"", concatenate("Bridge Trouble = ", Wireless_RSSI_a())) , "Can not read status of 1410 bridge")
VALUE:Wireless_RSSI_a()
Unit:db

HTH,
Lebowski

Note That the timers are modified for the "OID" function. If you don't modify the negative cache time any outage will last 300 seconds.

hi whats up with the probes and functions in ver4.0beta3.

I have followed wiki and lots of examples and cant get a probe of rssi to work.

Either it is showing signal low or not available.

I went back to basics and changed the mikrotik oid for my station for the example above and I still get nothing.

Well in this case "parse fail" which would indicate a missing parenthesis, but I have checked, I cannot see it.

Here is my modified function
if(array_size(oid_column("1.3.6.1.4.1.14988.1.1.1.1.1.4.3", 10 ,5)),oid_column("1.3.6.1.4.1.14988.1.1.1.1.1.4.3", 10, 5) ,"False")

Probe is as per detailed above.

If you take your oid and just place it on a label you can figure out what is wrong with it... Maybe the value is stored in the 0 pointer.

Put all of these on the device appearance and see if you get nothing or a value or an array of values. Some of them should show values and that should help you get the correct oid and the correct oid function to read them.
rssi1[oid_column("1.3.6.1.4.1.14988.1.1.1.1.1.4.3", 10, 5)]
rssi2[oid_column("1.3.6.1.4.1.14988.1.1.1.1.1.4.3.0", 10, 5)]
rssi3[oid("1.3.6.1.4.1.14988.1.1.1.1.1.4.3", 10, 5)]
rssi4[oid("1.3.6.1.4.1.14988.1.1.1.1.1.4.3.0", 10, 5)]
rssi5[oid_raw("1.3.6.1.4.1.14988.1.1.1.1.1.4.3", 10, 5)]
rssi6[oid_raw("1.3.6.1.4.1.14988.1.1.1.1.1.4.3.0", 10, 5)]

Thinking about the function part of the probe to read the values... What is going on in in the first half of the function is we are reading the entire column of values under the oid 1.3.6.1.4.1.14988.1.1.1.1.1.4.3 and if there are values in the array we should read a single oid with the value we are interested in 1.3.6.1.4.1.14988.1.1.1.1.1.4.3.0 otherwise return "False".

The point is the function determines if the OID even exists then returns a value or false.

HTH,
Lebowski

thanks.. I got it right later after I posted.. And now I see that the first half checks to see if the OID exists in the first place.

So everything is working fine and has been for a few weeks,, however I did not get an answer to the 10,5 entry at the tail end.

What is the significance of 10,5 ?

S

Cache time and negative cache time... the default for negative cache time is 300 seconds, that is how long the dude remembers that it could not retrieve a value. I can't think of any situation where you want a probe that fails to stay broken for 5 minutes. Cache time is handy when you are using an OID across a few probes or a few times in one probe and don't want the dude to poll the value for each use of the OID. With that said I have not tested cache time to see if the dude issues 3 SNMP reads if the same oid is used 3 times in one probe...

There is a really annoying detail in the dude that bugs me, when you hover on a device it shows a popup of items it reads from SNMP but it doesn't only read the items that are being shown, it seems the dude grabs the entire database. Oh well still going to move to another product in 6 months or less.

I really hate starting over...
Lebowski

Cache time and negative cache time... the default for negative cache time is 300 seconds, that is how long the dude remembers that it could not retrieve a value.

Hello & sorry for digging out out topic, do you have the knowledge if this behavior changed in new version of the dude? Do you use new version - what doesn't work, what problems did you have ? I personally still holding 4.03b, I've tested it few months ago and I've had some problems with native probes. They were constantly down or something like that, problems with displaying real time link throughput - [RX: Interface.InBitRate] in label instead of actual rate . Anything sounds familiar?

Sorry Eine I am not running the new version. I have been watching and there are good things in the newer versions but I have not had time to start a new server and migrate. I still run 4b3 and will migrate when i stop seeing game breaking bugs in the top of the forum. They should absolutely make negative cache time a variable on the device type. I can't understand why they have negative cache time but the programmer who wrote the dude is far better at this than I. Bugs aside if you can run 6x and identify things that are broke they seem to be responsive and trying to fix things so hopefully the new version will be viable sooner than later.

Thank you for your time.

Wow 4 and a half years later and I'm still searching for a solution and came upon my own thread lol. I'm starting my build using v6 and so far so good with most things, but the problem outlined in my first post still exists with it.

After 4.5 years I've gotten used to it and can live with it, but if anyone knows the secret handshake to make this thing work as expected, I'd love to hear from ya.

PS, to my future self in case I look again some time in the 2020's, hey dude!

Crazy stuff jmay, what I didn't try was to fix graphing negative numbers, I just graph the negative number from my radios. Maybe multiplying by -1 is storing the previous value and screwing up your probe? Anyhow you can graph negative numbers so maybe that would work...

Ok I figured out the new dude could graph negative numbers after I posted this so I took out the multiplication to make it a positive and it seems to work fine now. I was using dude 3.6 originally which forced me to do it that way.

Good to know jmay, another annoying dude thing resolved