Add OID to existing OS

It’s not graphing correctly to an RRD. Am I missing something else?
It shows 512 but then goes to 0 after the next poll.
Is there a way to graph it as an interger?

It means that the discovery is correct but not the polling.

Most probably, the num_oid part of the YAML file is wrong.

Try to do a
./poller.php -h <deviceID> -m sensors -v -d
And check the debug data. You’ll see that the OID is not polled as it should.

And by the way, QAM modulation is just a number, not a dBm, so you should probably use ‘count’ type and not ‘dbm’. I though the OID was the TX/RX power, but it is the type of modulation.

2 Likes

Thank-you so much for your time and assistance. I appreciate it greatly.

I did try the count sensor before but that wasn’t graphing too (not realising I had to do stuff with the poller) so I left it for now haha.

I’ll give it another go, thanks!

1 Like

Derova,
Was it just adding to the yaml file that did it?
If so, do you have an example to share… format, syntax, etc…
Thanks and Congrats!

Hey Sgroom,

Yes but there’s some other things I need to do to get it to work regarding the poller, I’ll hopefully be fixing it up today while at work and will provide you with the changes once I finish :slight_smile:

1 Like

@sgroom The steps are already described in the documentation ( OS Initial Detection ) and the following chapters.
You can then play with all the existing YAML files in order to find out how to add the OIDs you need.
Please submit a Pull Request in github to allow the community to use your add-ons and also allow your system to keep receiving updates.
Bye

1 Like

Hey PipoCanaja,

Sorry to bother you again. I found two issues.
You were correct, I made a typo in one of the num_oid lines (I missed the last period before the index).

SNMP[‘/usr/bin/snmpget’ ‘-v2c’ ‘-c’ ‘public’ ‘-OUQnte’ ‘-M’ ‘/opt/librenms/mibs:/opt/librenms/mibs/ceraos’ ‘-t’ ‘3’ ‘-r’ ‘5’ ‘udp: REDACTED:161’ ‘1.3.6.1.4.1.2281.10.7.4.1.1.6.268451969’ ‘1.3.6.1.4.1.2281.10.7.4.1.1.10268451969’]
.1.3.6.1.4.1.2281.10.7.4.1.1.1678517377 = No Such Object available on this agent at this OID
Error in packet
Reason: (genError) A general failure occured
Failed object: .1.3.6.1.4.1.2281.10.7.4.1.1.6.268451969
Checking (snmp) count The current TX QAM level…
Checking (snmp) count The current RX QAM level…

After fixing that up I get the following:

SNMP[‘/usr/bin/snmpget’ ‘-v2c’ ‘-c’ ‘public’ ‘-OUQnte’ ‘-M’ ‘/opt/librenms/mibs:/opt/librenms/mibs/ceraos’ ‘-t’ ‘3’ ‘-r’ ‘5’ ‘udp: REDACTED:161’ ‘1.3.6.1.4.1.2281.10.7.4.1.1.6.268451969’ ‘1.3.6.1.4.1.2281.10.7.4.1.1.10.268451969’]
.1.3.6.1.4.1.2281.10.7.4.1.1.6.268451969 = 512
.1.3.6.1.4.1.2281.10.7.4.1.1.10.268451969 = 512

Checking (snmp) count The current TX QAM level…
Checking (snmp) count The current RX QAM level…

Warning: A non-numeric value encountered in /opt/librenms/includes/polling/functions.inc.php on line 167
0
RRD[last REDACTED/sensor-count-ceraos-genEquipRadioMRMCCurrTxQAM.268451969.rrd --daemon 10.100.0.61:42217]
RRDtool Output: 1562712600
OK u:0.01 s:0.00 r:9.12
RRD[update REDACTED/sensor-count-ceraos-genEquipRadioMRMCCurrTxQAM.268451969.rrd N:0 --daemon 10.100.0.61:42217]
RRDtool Output: OK u:0.00 s:0.00 r:9.08

Warning: A non-numeric value encountered in /opt/librenms/includes/polling/functions.inc.php on line 167
0
RRD[last REDACTED/sensor-count-ceraos-genEquipRadioMRMCCurrRxQAM.268451969.rrd --daemon 10.100.0.61:42217]
RRDtool Output: 1562712600
OK u:0.01 s:0.00 r:9.12
RRD[update REDACTED/sensor-count-ceraos-genEquipRadioMRMCCurrRxQAM.268451969.rrd N:0 --daemon 10.100.0.61:42217]
RRDtool Output: OK u:0.00 s:0.00 r:9.12
SQL[SELECT * FROM sensors WHERE sensor_class = ? AND device_id = ? [“state”,222] 0.49ms]

Line 167 on Functions is:

$sensor_value = ($sensor_value / $sensor[‘sensor_divisor’]);

I tried adding “divisor: 0” and also tried “divisor: 100” to the yaml, then doing a rediscovery / poll but that didn’t make any difference.

It’s showing the expected output of 512 for those OIDS, I’m guessing I might need to make a new sensor type per: Wireless Sensors - LibreNMS Docs

Edit:
I think it’s related to this issue that’s possibly unsolved?

LibreNMS is expecting a string value, but the device is providing an integer.

snmpwalk -v 2c -c REDACTED STRING REDACTED IP 1.3.6.1.4.1.2281.10.7.4.1.1.10.268451969
SNMPv2-SMI::enterprises.2281.10.7.4.1.1.10.268451969 = INTEGER: 512

snmpwalk -v 2c -c REDACTED STRING REDACTED IP 1.3.6.1.4.1.2281.10.7.4.1.1.6.268451969
SNMPv2-SMI::enterprises.2281.10.7.4.1.1.6.268451969 = INTEGER: 512

Basically, SNMP replies an INTEGER and LibreNMS expects a numeric value so it should be all right.
Would you mind posting the current “count” block of your yaml file ?

count:
  data:
    -
      oid: genEquipRadioMRMCCurrTxQAM
      value: genEquipRadioMRMCCurrTxQAM
      num_oid: 1.3.6.1.4.1.2281.10.7.4.1.1.6.{{ $index }}
      descr: The current TX QAM level
      index: genEquipRadioMRMCCurrTxQAM.{{ $index }}
    -
      oid: genEquipRadioMRMCCurrRxQAM
      value: genEquipRadioMRMCCurrRxQAM
      num_oid: 1.3.6.1.4.1.2281.10.7.4.1.1.10.{{ $index }}
      descr: The current RX QAM level
      index: genEquipRadioMRMCCurrRxQAM.{{ $index }}

I don’t see anything that could explain the message. Don’t put any multiplier or divisor as the value is already correct, and already a number.

Stupid question : did you re-run the discovery after each change of YAML file ?

You can add some d_echo() calls to display some variables and find out which var is wrong around line 167, and get back to the source of the issue.

You could remove value: genEquipRadioMRMCCurrTxQAM from the file because genEquipRadioMRMCCurrTxQAM is the exact value you are polling in this configuration.
Or you could put oid: genEquipRadioMRMCTable and keep value: genEquipRadioMRMCCurrTxQAM but this is not linked to your issue.

Yeah I removed the Divisor as I temporarily added it just for testing.

That’s correct I re-ran the discovery after each change to the YAML - when I fixed the num_oid typo the error was different with the poller debug.

Thanks for the information, I’ll have another go today and let you know.

Again as always appreciate the assistance.

Found it!
TL;DR: The num_oid lines in my yaml were missing the leading ‘.’.
Such a simple oversight on my part.

SNMP Command = Array
SNMP[‘/usr/bin/snmpget’ ‘-v2c’ ‘-c’ ‘public’ ‘-OUQnte’ ‘-M’ ‘/opt/librenms/mibs:/opt/librenms/mibs/ceraos’ ‘-t’ ‘3’ ‘-r’ ‘5’ ‘udp:REDACTED:161’ ‘1.3.6.1.4.1.2281.10.7.4.1.1.6.268451969’ ‘1.3.6.1.4.1.2281.10.7.4.1.1.10.268451969’]
.1.3.6.1.4.1.2281.10.7.4.1.1.6.268451969 = 512
.1.3.6.1.4.1.2281.10.7.4.1.1.10.268451969 = 512

Output snmp_get_multi_oid = Array
(
[.1.3.6.1.4.1.2281.10.7.4.1.1.6.268451969] => 512
[.1.3.6.1.4.1.2281.10.7.4.1.1.10.268451969] => 512
)
bulk_sensor_snmpget output = Array
(
[.1.3.6.1.4.1.2281.10.7.4.1.1.6.268451969] => 512
[.1.3.6.1.4.1.2281.10.7.4.1.1.10.268451969] => 512
)
Checking (snmp) count The current TX QAM level…
SNMP Data = Array
(
[.1.3.6.1.4.1.2281.10.7.4.1.1.6.268451969] => 512
[.1.3.6.1.4.1.2281.10.7.4.1.1.10.268451969] => 512
)
sensor @ 71 =Array
(
[sensor_id] => 3143
[sensor_deleted] => 0
[sensor_class] => count
[device_id] => 222
[poller_type] => snmp
[sensor_oid] => 1.3.6.1.4.1.2281.10.7.4.1.1.6.268451969
[sensor_index] => genEquipRadioMRMCCurrTxQAM.268451969
[sensor_type] => ceraos
[sensor_descr] => The current TX QAM level
[group] =>
[sensor_divisor] => 1
[sensor_multiplier] => 1
[sensor_current] => 0
[sensor_limit] =>
[sensor_limit_warn] =>
[sensor_limit_low] =>
[sensor_limit_low_warn] =>
[sensor_alert] => 1
[sensor_custom] => No
[entPhysicalIndex] =>
[entPhysicalIndex_measured] =>
[lastupdate] => 2019-07-11 13:27:09
[sensor_prev] => 512
[user_func] =>
)
Sensor New Value =
Checking (snmp) count The current RX QAM level…
SNMP Data = Array
(
[.1.3.6.1.4.1.2281.10.7.4.1.1.6.268451969] => 512
[.1.3.6.1.4.1.2281.10.7.4.1.1.10.268451969] => 512
)
sensor @ 71 =Array
(
[sensor_id] => 3144
[sensor_deleted] => 0
[sensor_class] => count
[device_id] => 222
[poller_type] => snmp
[sensor_oid] => 1.3.6.1.4.1.2281.10.7.4.1.1.10.268451969
[sensor_index] => genEquipRadioMRMCCurrRxQAM.268451969
[sensor_type] => ceraos
[sensor_descr] => The current RX QAM level
[group] =>
[sensor_divisor] => 1
[sensor_multiplier] => 1
[sensor_current] => 0
[sensor_limit] =>
[sensor_limit_warn] =>
[sensor_limit_low] =>
[sensor_limit_low_warn] =>
[sensor_alert] => 1
[sensor_custom] => No
[entPhysicalIndex] =>
[entPhysicalIndex_measured] =>
[lastupdate] => 2019-07-11 13:27:09
[sensor_prev] => 1024
[user_func] =>
)
Sensor New Value =
Raw Sensor = Array
(
[sensor_id] => 3143
[sensor_deleted] => 0
[sensor_class] => count
[device_id] => 222
[poller_type] => snmp
[sensor_oid] => 1.3.6.1.4.1.2281.10.7.4.1.1.6.268451969
[sensor_index] => genEquipRadioMRMCCurrTxQAM.268451969
[sensor_type] => ceraos
[sensor_descr] => The current TX QAM level
[group] =>
[sensor_divisor] => 1
[sensor_multiplier] => 1
[sensor_current] => 0
[sensor_limit] =>
[sensor_limit_warn] =>
[sensor_limit_low] =>
[sensor_limit_low_warn] =>
[sensor_alert] => 1
[sensor_custom] => No
[entPhysicalIndex] =>
[entPhysicalIndex_measured] =>
[lastupdate] => 2019-07-11 13:27:09
[sensor_prev] => 512
[user_func] =>
[new_value] =>
)
Sensor Value = ‘’ | Sensor Divisor = ‘1’

Warning: A non-numeric value encountered in /opt/librenms/includes/polling/functions.inc.php on line 173
0
RRD[last REDACTED/sensor-count-ceraos-genEquipRadioMRMCCurrTxQAM.268451969.rrd --daemon 10.100.0.61:42217]
RRDtool Output: 1563234000
OK u:0.00 s:0.01 r:9.13
RRD[update REDACTED/sensor-count-ceraos-genEquipRadioMRMCCurrTxQAM.268451969.rrd N:0 --daemon 10.100.0.61:42217]
RRDtool Output: OK u:0.00 s:0.00 r:9.09
Raw Sensor = Array
(
[sensor_id] => 3144
[sensor_deleted] => 0
[sensor_class] => count
[device_id] => 222
[poller_type] => snmp
[sensor_oid] => 1.3.6.1.4.1.2281.10.7.4.1.1.10.268451969
[sensor_index] => genEquipRadioMRMCCurrRxQAM.268451969
[sensor_type] => ceraos
[sensor_descr] => The current RX QAM level
[group] =>
[sensor_divisor] => 1
[sensor_multiplier] => 1
[sensor_current] => 0
[sensor_limit] =>
[sensor_limit_warn] =>
[sensor_limit_low] =>
[sensor_limit_low_warn] =>
[sensor_alert] => 1
[sensor_custom] => No
[entPhysicalIndex] =>
[entPhysicalIndex_measured] =>
[lastupdate] => 2019-07-11 13:27:09
[sensor_prev] => 1024
[user_func] =>
[new_value] =>
)
Sensor Value = ‘’ | Sensor Divisor = ‘1’

Warning: A non-numeric value encountered in /opt/librenms/includes/polling/functions.inc.php on line 173
0

Added below to the OS YAML file and did a rediscover.

count:
data:
-
oid: genEquipRadioMRMCCurrTxQAM
value: genEquipRadioMRMCCurrTxQAM
num_oid: .1.3.6.1.4.1.2281.10.7.4.1.1.6.{{ $index }}
descr: The current TX QAM level
index: genEquipRadioMRMCCurrTxQAM.{{ $index }}
-
oid: genEquipRadioMRMCCurrRxQAM
value: genEquipRadioMRMCCurrRxQAM
num_oid: .1.3.6.1.4.1.2281.10.7.4.1.1.10.{{ $index }}
descr: The current RX QAM level
index: genEquipRadioMRMCCurrRxQAM.{{ $index }}

@PipoCanaja
Sorry one last thing before I do a Pull Request.
In the interest of keeping it clean, is there a way to move it from “Health” to “Wireless” and change the name from “Count” to “QAM”?

Not using the YAML file for ‘simple’ discovery. You would need to follow this doc :
https://docs.librenms.org/Developing/os/Wireless-Sensors/
Not at all the same logic, and coding is mandatory here.

That being said, concerning your current YAML, I have a remark :

num_oid: .1.3.6.1.4.1.2281.10.7.4.1.1.6.{{ $index }}
descr: The current TX QAM level

The description is “fixed” which means that if the device reports multiple QAM levels for multiple interfaces, they will all share the same description. Usually, an OID has the interface name (or entity) associated with $index, and you use this to create dynamically the descr. If none are available, at least you add $index to the description, so they get a different number appended.

Thanks again for your help!

@Derova - Did this work ever get submitted as a PR? We have a bunch of Ceragon we are looking to monitor too.

Hi djh00t,

No sorry it wasn’t submitted as a PR.
Are you wanting to be able to monitor the same QAM values per the original post?

Certainly are! Overall Ceraos coverage isn’t great right now, we’re looking at spending some time on it but don’t want to reinvent the wheel.