ValueCallback *addFloatHandler

[olego-nn]

Hi.
I'm polling the Agent from the linux console:
/usr/bin/snmpget -v1 -t 10 -c public 10.100.198.250 .1.3.6.1.4.1.3049.1.13.0
I get the response:
SNMPv2-SMI::enterprises.3049.1.13.0 = Opaque: Float: 13.100000
I.e. Float data type.
If I use SnmpManager on ESP32 and use the following to request the specified parameter:
callbackBattery = snmpManager.addFloatHandler(target, ".1.3.6.1.4.1.3049.1.13.0", &Battery);
where I declare Battery as float Battery then the error:
Incorrect Callback type. Expected: 2 Received: 68 - When calling: .1.3.6.1.4.1.3049.1.13.0

Debug log in file

debug_log.txt

Please tell me what to pay attention to

[shortbloke]

Hi based on the response, the device being polled is returning datatype 68 (0x44) which maps to the OPAQUE data type.

Floats are typically presented as integers with a known divisor to get to a float, some systems will attempt to send float values as strings to get around this limitation of the SNMP spec.

The error is reporting it's actually expecting and integer, 0x02, but getting this opaque type which isn't handled.

In RFC1902, this type was provided for backward compatibility only, and that implementations of that standard are not required to unwrap data.

7.1.9. Opaque
The Opaque type is provided solely for backward-compatibility, and
shall not be used for newly-defined object types.
The Opaque type supports the capability to pass arbitrary ASN.1
syntax. A value is encoded using the ASN.1 Basic Encoding Rules [4]
into a string of octets. This, in turn, is encoded as an OCTET
STRING, in effect "double-wrapping" the original ASN.1 value.
Note that a conforming implementation need only be able to accept and
recognize opaquely-encoded data. It need not be able to unwrap the
data and then interpret its contents.
A requirement on "standard" MIB modules is that no object may have a
SYNTAX clause value of Opaque.

Do you have any control of the device you are querying to determine if there is a different OID with a different datatype for the battery value?

Else the next option would be to return the opaque return value and require you to figure out how to decode it, it may be possible to return this as a string of hex values, but I'm not sure if that would be of any use? It certainly wouldn't be a float, as that's not what is being returned as the data type from the device. The third option would be to implement a handler for opaque types that tried to parse the payload and work out what type it's claiming to be.

If you wish to submit a PR for implementing a solution, I'm happy to consider it, but it's not a request I've had before, so unclear of the value of extending support for this deprecated type.

Martin

[olego-nn]

Hi Martin. Thank you very much for your response. The device being accessed by the Snmp manager is an industrial device and its software cannot be upgraded. This device is rarely used (not popular), so it would be unnecessary to make changes to your software for this purpose.

Oleg