Is it possible to create such code in Dude for device monitoring?

Hello. I need at least knowing advice on subject. Working code of course are welcome! :smiley:
Please advice, is described task can be done in Dude or not?

1)Create device “Watch server” in Dude (SNMP Agent, V2, public) - done
2)Create device “Repeater” in Dude (ping only, no SNMP) - done
CustomField1 = IP Address of Watch Server
CustomField2 = SNMP Id of Repeater on Watch Server
3) Create Function|Probe to get from Watch server Alarm List for Repeater. - work in progress, hope i’ll win this fight with Dude :smiley:
[indexValue] entPhysicalTable_IndexValue=[array_element(oid_column(“1.3.6.1.2.1.47.1.1.1”,5,300,device_property(“CustomField1”),“public”),device_property(“CustomField2”)-1)]
[integer32] entPhysicalContainedIn=[oid(“1.3.6.1.2.1.47.1.1.1.1.4.R_IndexValue”,5,300,device_property(“CustomField1”),“public”)]
[octet string] ceAlarmList=[oid(“1.3.6.1.4.1.9.9.138.1.2.5.1.3.R_entPhysicalContainedIn”,5,300,device_property(“CustomField1”),“public”)]

Get Result like: ceAlarmList=[octet string] HEX 00 00 00 00 00 00 00 0E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  1. Parse ceAlarmList to Array of Alarm Codes? - got no idea how to do this math
    7*8 + 1|2|3 (00001110) = 57|58|59

Alarms code calculation:
1)78 + 1 = 57 (Alarm text: Low battery)
2)7
8 + 2 = 58 (Alarm text: Bad Battery)
3)7*8 + 3 = 59 (Alarm text: Battery Disconnected)

Descriptions of alarms (code, severity, message): 1-63, 70-72, 74-76, 78-82, 84, 107 located in ceAlarmDescrTable

  1. For each Alarm Code do Alarm Message Lookup and Alarm Severity translation from digit to Text - looks not so hard
    from ceAlarmDescrTable
    AlarmMessage = [oid(“1.3.6.1.4.1.9.9.138.1.1.2.1.3.1.AlarmCode”,5,300,device_property(“CustomField1”),“public”)]
    AlarmSeverity = [oid(“1.3.6.1.4.1.9.9.138.1.1.2.1.2.1.AlarmCode”,5,300,device_property(“CustomField1”),“public”)]

AlarmSeverityText = 1=(C)ritical, 2=(M)ajor, 3=(m)inor, 4=(I)nfo

  1. Finally somehow print on Device Label all current alarms with severity - no idea if some type of array can be printed there
    Low battery (m)
    Bad battery (m)
    Battery disconnected (m)


    ======== From manual========================
    The ceAlarmList object (ceAlarmTable, Oid: 1.3.6.1.4.1.9.9.138.1.2.5.1.3) contains alarms as 32-byte strings in hexadecimal format.
    Note: If no alarm is set, ceAlarmList will contain an empty string (zero length).
    The ordinal bits in the string specify the alarm code.
    For example, you get an alarm encoded in the following string:
    00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    You see 13 bytes holding zeroes and then a byte holding information. In this byte, (08) stands for (00001000) in binary format.
    Bits in the byte ‘08’ are indexed from right to left, so the position of the ordinal bit is 3.
    Calculate the alarm code:
    13*8 (the number of ‘zero’ bits prior to byte ‘08’) + 3 (00001000)= 107
    Code 107 = “Peer disconnected.”

Any ideas how to treat octet string which is not all zeroes?

[oid(concatenate(“1.3.6.1.4.1.9.9.138.1.2.5.1.3.”,oid(concatenate(“1.3.6.1.2.1.47.1.1.1.1.4.”,array_element(oid_column(“1.3.6.1.2.1.47.1.1.1”,5,300,device_property(“CustomField1”),“public”),device_property(“CustomField2”)-1)),5,300,device_property(“CustomField1”),“public”)),5,300,device_property(“CustomField1”),“public”)] shows nothing, and I am unable to analyze this data in any way.
with alarms.png
I tried to select another device, without alarms, so result is empty string, and does not seen any difference.

To do math, you can use ros_command function, and provide RouterOS script since that can deal with bit operations.

To display some kinda enum, that’s tricker… theoretically one approach be use a probe, with a Function type, and use “units” for your text formatting.

I wrote up using the Dude to monitor LTE signal, which is very loosely similar to problems here. One tip from that be using multiple functions help to organize things does help as the syntax can get long and difficult to debug if you try to string together too many things in one operation.