Riello SNMP : ".1.3.6.1.4.1.5491.6" sysOID (NetManPlus 102)

[masterx1981]

Riello SNMP : ".1.3.6.1.4.1.5491.6" sysOID (NetManPlus 102)

[jimklimov]

Hi, thanks for the question and archives!

I am not sure all the MIBs in the ZIP are even all valid - it seems they took a generated (paginated) text file for e.g. RFC3433 and spliced its text with MIB markup. Most of the paginations landed into text-convention blocks, but some are outside (e.g. Pages 10, 11, 12) - at element-definition level :-\

Back to your question: https://github.com/networkupstools/nut/blob/master/docs/snmp-subdrivers.txt / rendered version at https://networkupstools.org/docs/developer-guide.chunked/new-drivers.html#snmp-subdrivers has a chapter on "Creating a subdriver". It is at least a good starting point...

[masterx1981]

Hi, thanks for the question and archives!

I am not sure all the MIBs in the ZIP are even all valid - it seems they took a generated (paginated) text file for e.g. RFC3433 and spliced its text with MIB markup. Most of the paginations landed into text-convention blocks, but some are outside (e.g. Pages 10, 11, 12) - at element-definition level :-\

Back to your question: https://github.com/networkupstools/nut/blob/master/docs/snmp-subdrivers.txt / rendered version at https://networkupstools.org/docs/developer-guide.chunked/new-drivers.html#snmp-subdrivers has a chapter on "Creating a subdriver". It is at least a good starting point...

Thanks for the fast answer!
I'll try to follow the guides, in the hope than doing it in an haasio installation isn't too difficilt...
As soon as i have some free time i'll play with it, thanks!

[jimklimov]

If you mean generation of the sub-driver in an existing installation - not sure about that. The scripts and general procedure involved here assumes working with NUT sources (eventually to build it into a binary to test the updated driver).

Afterwards however it should be possible to build a custom Home Assistant plugin container - some community members contributed the procedures that are now on the Wiki, but I've not used nor done that myself.

[masterx1981]

If you mean generation of the sub-driver in an existing installation - not sure about that. The scripts and general procedure involved here assumes working with NUT sources (eventually to build it into a binary to test the updated driver).

Afterwards however it should be possible to build a custom Home Assistant plugin container - some community members contributed the procedures that are now on the Wiki, but I've not used nor done that myself.

Wow, seem a quite hard way for implement it...
Hope to find an easyier way to handle it in HA.

Thanks!

[masterx1981]

Sorry, i've seen that the snmp walk kog identifies 2 different oids, one is the unknown one l, the other one is OID=.1.3.6.1.2.1.33, that seem standard ietf, and the voltage/frequency seem that are under this id.
But why aren't read by the nut service?
I'm using this device configuration:

- name: riello
  driver: snmp-ups
  port: 192.168.1.183
  desc: Riello Sentinel 5000VA
  snmp_version: v1
  mibs: ietf
  pollinterval: 15
  upsmon_deadtime: 25
  config: []

[jimklimov]

Hm, that seems to be missing a community: public line (or whatever your credential is - note that for instant commands and variable setting, you'd need to enable an RW community like "private" on the device and pass it to NUT).

[masterx1981]

Hm, that seems to be missing a community: public line (or whatever your credential is - note that for instant commands and variable setting, you'd need to enable an RW community like "private" on the device and pass it to NUT).

I've not put the community line as on the configuration manuals is specified that the community option have a default value of "public", that match the read only community set on the interface card. In any case, i'll try to add it.

And, how i can set the write community? The neteork card is set to "private"

---Edit---

I've noticed also this strange line on the nut log:
Detected 0 on host 192.168.1.183 (mib: apc_ats 0.6)
Why there is that apc_ats mib, while i've configured ietf ?

[jimklimov]

Yeah, "public" should be default, even per codebase:

drivers/snmp-ups.c:               community = testvar(SU_VAR_COMMUNITY) ? getval(SU_VAR_COMMUNITY) : "public";

FWIW, communities are used with SNMP versions v1 and v2c (but not 3) - so maybe you can try v2c if your card likes it better?..

Maybe you can bump debug_min 6 for that driver (or export a NUT_DEBUG_LEVEL=6 envvar) to show more logs - in particular, trace if it gets the mibs setting and what else it tries?

I have no idea how HA is set up and what info it passes into the actual NUT configs, so have a hard time figuring out from the piecemeal info if it is even a NUT bug or a HA bug...

That said, normally snmp-ups without a (seen) mibs parameter should try all known mappings and ietf in the end. So it probably stumbles upon seeing a reply from the device. Maybe the HA firewall (or generally container networking) is playing tricks or something - apc_ats is likely just the first MIB tried:

$ NUT_STATEPATH=/tmp ./drivers/snmp-ups -x mibs=--list -s test -x port=x
Network UPS Tools - Generic SNMP UPS driver 1.30 (2.8.1-221-gd8b254dbe)
The 'mibs' argument is '--list', so just listing the mappings this driver knows,
and for 'mibs=auto' these mappings will be tried in the following order until
the first one matches your device

 NUMBER MAPPING NAME            VERSION ENTRY POINT OID                 AUTO CHECK OID
    1   apc_ats                     0.6 .1.3.6.1.4.1.318.1.3.11         .1.3.6.1.4.1.318.1.1.8.1.5.0
    2   apc_pdu                     0.4 .1.3.6.1.4.1.318.1.3.4.4        .1.3.6.1.4.1.318.1.1.4.1.4.0
    3   apc_pdu                     0.4 .1.3.6.1.4.1.318.1.3.4.5        .1.3.6.1.4.1.318.1.1.4.1.4.0
    4   apc_pdu                     0.4 .1.3.6.1.4.1.318.1.3.4.6        .1.3.6.1.4.1.318.1.1.4.1.4.0
    5   apc                         0.1 .1.3.6.1.4.1.318.1.3.4.9        <NULL>
    6   apcc                        1.6 .1.3.6.1.4.1.318.1.1.1.1.1.1.0  .1.3.6.1.4.1.318.1.1.1.1.1.1.0
    7   baytech                  0.4035 .1.3.6.1.4.1.4779               .1.3.6.1.4.1.4779.1.3.5.2.1.24.1
    8   bestpower                   0.4 .1.3.6.1.4.1.2947.1.1.2.0       .1.3.6.1.4.1.2947.1.1.2.0
    9   cpqpower                   1.67 .1.3.6.1.4.1.232.165.3          .1.3.6.1.4.1.232.165.3.1.1.0
   10   cyberpower                 0.55 .1.3.6.1.4.1.3808.1.1.1         .1.3.6.1.4.1.3808.1.1.1.1.1.1.0
   11   cyberpower                 0.55 .1.3.6.1.4.1.3808               .1.3.6.1.4.1.3808.1.1.1.1.1.1.0
   12   delta_ups                   0.5 .1.3.6.1.4.1.2254.2.4           <NULL>
   13   eaton_ats16_nmc            0.21 .1.3.6.1.4.1.705.1              .1.3.6.1.4.1.534.10.2.1.2.0
   14   eaton_ats16_nm2            0.22 .1.3.6.1.4.1.534.10.2           .1.3.6.1.4.1.534.10.2.1.2.0
   15   eaton_ats30                0.03 .1.3.6.1.4.1.534.10.1           .1.3.6.1.4.1.534.10.1.2.1.0
   16   eaton_epdu                 0.69 .1.3.6.1.4.1.534.6.6.7          .1.3.6.1.4.1.534.6.6.7.1.2.1.2.0
   17   eaton_pdu_nlogic            0.1 .1.3.6.1.4.1.534.7.1            <NULL>
   18   eaton_pxg_ups             0.105 .1.3.6.1.4.1.534.2.12           1.3.6.1.4.1.534.1.1.2.0
   19   eaton_pw_nm2              0.105 .1.3.6.1.4.1.534.1              1.3.6.1.4.1.534.1.1.2.0
   20   emerson_avocent_pdu         1.3 .1.3.6.1.4.1.10418.17.1.7       .1.3.6.1.4.1.10418.17.2.1.2.0
   21   aphel_revelation           0.52 .1.3.6.1.4.1.534.6.6.6          .1.3.6.1.4.1.534.6.6.6.1.1.12.0
   22   aphel_genesisII            0.52 .1.3.6.1.4.1.17373              .1.3.6.1.4.1.17373.3.1.1.0
   23   pulizzi_switched1           0.5 .1.3.6.1.4.1.20677.1            .1.3.6.1.4.1.20677.1
   24   pulizzi_switched2           0.5 .1.3.6.1.4.1.20677.2            .1.3.6.1.4.1.20677.1
   25   hpe_epdu                   0.33 .1.3.6.1.4.1.232.165.7          .1.3.6.1.4.1.232.165.7.1.2.1.3.0
   26   hpe_pdu3_cis                0.1 .1.3.6.1.4.1.232.165.11         .1.3.6.1.4.1.232.165.11.1.2.1.3.1
   27   huawei                      0.4 .1.3.6.1.4.1.8072.3.2.10        .1.3.6.1.4.1.2011.6.174.1.2.100.1.2.1
   28   mge                        0.55 .1.3.6.1.4.1.705.1              .1.3.6.1.4.1.705.1.1.1.0
   29   netvision                  0.44 .1.3.6.1.4.1.4555.1.1.1         .1.3.6.1.4.1.4555.1.1.1.1.1.1.0
   30   raritan                     0.8 .1.3.6.1.4.1.13742              .1.3.6.1.4.1.13742.1.1.12.0
   31   raritan-px2                 0.4 .1.3.6.1.4.1.13742.6            .1.3.6.1.4.1.13742.6.3.2.1.1.3.1
   32   xppc                        0.4 .1.3.6.1.4.1.935                <NULL>
   33   tripplite                  1.55 .1.3.6.1.4.1.850.1              <NULL>
   34   ietf                       1.55 .1.3.6.1.2.1.33                 1.3.6.1.2.1.33.1.1.1.0

Overall this driver has loaded 34 MIB-to-NUT mapping tables
upsnotify: notify about state 4 with libsystemd: was requested, but not running as a service unit now, will not spam more about it
upsnotify: failed to notify about state 4: no notification tech defined, will not spam more about it

Notably, with SNMP being UDP-based (no sessions to establish and break), a lack of response due to bad password/community is not distinguishable from lack of network access (routing, firewall, etc.) which often leads to grief setting up new devices and not seeing them. Here the driver claims seeing a (bogus) response so that may be something else.

And, how i can set the write community? The neteork card is set to "private"

If that is enabled on the UPS card (often there's a separate toggle to actually enable the R/W community) then you just use that community name in the NUT driver config. An R/W one has all the access needed of an R/O community, and more (for setvar and cmd writes).

Just in case, if that private is the ONLY community enabled on the card, that could be consistent with not seeing replies for a public access...

[masterx1981]

Current config, with log level set to debug:

users:
  - username: xxx
    password: yyy
    instcmds:
      - all
    actions: []
devices:
  - name: riello
    driver: snmp-ups
    port: 192.168.1.183
    desc: Riello Sentinel 5000VA
    snmp_version: v2c
    community: public
    mibs: ietf
    pollinterval: 15
    upsmon_deadtime: 25
    config: []
mode: netserver
shutdown_host: false
log_level: debug

Got this log:

s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service base-addon-banner: starting

-----------------------------------------------------------
 Add-on: Network UPS Tools
 Manage battery backup (UPS) devices
-----------------------------------------------------------
 Add-on version: 0.12.2
 You are running the latest version of this add-on.
 System: Home Assistant OS 11.2  (aarch64 / raspberrypi4-64)
 Home Assistant Core: 2023.12.0
 Home Assistant Supervisor: 2023.11.6
-----------------------------------------------------------
 Please, share the above information when looking for help
 or support in, e.g., GitHub, forums or the Discord chat.
-----------------------------------------------------------
s6-rc: info: service base-addon-banner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service base-addon-timezone: starting
s6-rc: info: service base-addon-log-level: starting
s6-rc: info: service fix-attrs successfully started
[10:25:14] INFO: Configuring timezone (Europe/Rome)...
Log level is set to DEBUG
s6-rc: info: service base-addon-log-level successfully started
s6-rc: info: service base-addon-timezone successfully started
s6-rc: info: service legacy-cont-init: starting
cont-init: info: running /etc/cont-init.d/nut.sh
[10:25:16] INFO: Setting mode to netserver...
[10:25:16] INFO: Generating /etc/nut/upsd.users...
[10:25:17] INFO: Configuring user: masterx81
[10:25:17] DEBUG: Password SHA1: xxxxxx
[10:25:17] DEBUG: Requested API resource: https://api.pwnedpasswords.com/range/6DB5F
[10:25:17] DEBUG: API HTTP Response code: 200
[10:25:17] INFO: Password is NOT in the Have I Been Pwned database! Nice!
[10:25:19] INFO: Configuring Device named riello...
[10:25:19] INFO: Starting the UPS drivers...
   0.000000	[D1] Starting UPS: riello
Created directory: /var/lib/snmp/cert_indexes
No matching MIB found for sysOID '.1.3.6.1.4.1.5491.6'!
Please report it to NUT developers, with an 'upsc' output for your device.
Going back to the classic MIB detection method.
No matching MIB found for sysOID '.1.3.6.1.4.1.5491.6'!
Please report it to NUT developers, with an 'upsc' output for your device.
Going back to the classic MIB detection method.
No matching MIB found for sysOID '.1.3.6.1.4.1.5491.6'!
Please report it to NUT developers, with an 'upsc' output for your device.
Going back to the classic MIB detection method.
Detected 0 on host 192.168.1.183 (mib: apc_ats 0.6)
Network UPS Tools - UPS driver controller 2.8.0
cont-init: info: /etc/cont-init.d/nut.sh exited 0
cont-init: info: running /etc/cont-init.d/nutclient.sh
cont-init: info: /etc/cont-init.d/nutclient.sh exited 0
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
services-up: info: copying legacy longrun upsd (no readiness notification)
services-up: info: copying legacy longrun upsmon (no readiness notification)
s6-rc: info: service legacy-services successfully started
[10:25:24] INFO: Starting the UPS information server...
   0.000000	fopen /run/nut/upsd.pid: No such file or directory
   0.000076	Could not find PID file '/run/nut/upsd.pid' to see if previous upsd instance is already running!

   0.001958	[D1] debug level is '1'
   0.002948	listening on 0.0.0.0 port 3493
   0.004200	Connected to UPS [riello]: snmp-ups-riello
   0.006628	Running as foreground process, not saving a PID file
[10:25:24] INFO: Starting the UPS monitor and shutdown controller...
   0.000000	fopen /run/nut/upsmon.pid: No such file or directory
   0.000325	Could not find PID file to see if previous upsmon instance is already running!

   0.001003	Using power down flag file /etc/killpower
   0.001518	UPS: riello@localhost (primary) (power value 1)
   0.001764	[D1] debug level is '1'
   0.002053	[D1] debug level is '1'
   0.002242	Warning: running as one big root process by request (upsmon -p)
   0.002652	[D1] Saving PID 466 into /run/nut/upsmon.pid
Init SSL without certificate database
   0.010057	[D1] Trying to connect to UPS [riello@localhost]
   0.560301	User [email protected] logged into UPS [riello]
   0.013766	[D1] Logged into UPS riello@localhost
{"message":"Event nut.ups_event fired."}Network UPS Tools upsmon 2.8.0
{"message":"Event nut.ups_event fired."}Network UPS Tools upsmon 2.8.0

Setting to "private" community not change nothing....
Thanks for the support!

[jimklimov]

Well, here it seems NUT snmp-ups driver does get a reply to initial query for a sysOID (roughly "where do I get best detailed info?") which is usually a vendor-extension branch of the data tree.

That sysOID is not known to our mapping tables (see generation of subdriver discussed above), so snmp-ups falls back to picking one. Apparently the mibs setting does not make it through HA. Can you log into the container (exec a shell in it) or otherwise look at the ups.conf file that HA creates?

Not sure what their log_level: debug sets up, but I've seen just a few lines with [D1] in your recent post (and a statement of "debug level: 1") so it is a minimally verbose mode...

[masterx1981]

I've tried to set a more detailed loglevel (trace), but i still see the D1 lines, and seem only to add debug information of the ha side.
I know that hassio create an environment for every addon, but by now i not know how to access to the data of a specific container.
I've noticed that ha have a function to read an snmp sensor using the snmp platform, and passing the : .1.3.6.1.2.1.33.1.2.7.0 baseoid i'm able to directly read the temperature of the unit, in case i fail to usa nut, i'll use this method, far from optimal, but at least seem to work 😅

[masterx1981]

Well, here it seems NUT snmp-ups driver does get a reply to initial query for a sysOID (roughly "where do I get best detailed info?") which is usually a vendor-extension branch of the data tree.

That sysOID is not known to our mapping tables (see generation of subdriver discussed above), so snmp-ups falls back to picking one. Apparently the mibs setting does not make it through HA. Can you log into the container (exec a shell in it) or otherwise look at the ups.conf file that HA creates?

Not sure what their log_level: debug sets up, but I've seen just a few lines with [D1] in your recent post (and a statement of "debug level: 1") so it is a minimally verbose mode...

I'm trying a bit to understand the snmp message structure, comparing mib with snmpwalk, i understad what you was saying, and that is right. On oid .1.3.6.1.2.1.1.2.0 my card send an oid of 1.3.6.1.4.1.5491.6, that is the one not recognized. When nut recognize that it not know this oid, simply fail, ignoring as you said the mib definition specified in the config.
But i not know why then it tries to decode the messages using only the first driver of the list, and then exiting.
Most of the messages that i see with snmpwalk are ietf compatible, and only a small parts are of the unrecognized oid.
A good logic would be: if the card specifies a custom oid, nut must try to use that, if it not know the oid (or if the card not send it), try to use the forced one. If also this one doesn't allow to decode, then iterate through the list until it find something

[jimklimov]

To help dissect which part of the data conveyor belt has the actual issue, can you run NUT on the native system, where you have control over configs made, debugs collected, etc.?

That wiki article on "in-place" builds has links to a document with prerequisite packages for various platforms, and stipulates that you don't have to make install NUT into your system and how you can run the freshly built drivers right from that workspace to test them.

[masterx1981]

As soon as i have some spare time i try to get access to the bare hassos, and move from there to spot the problem. Seem a not easy procedure that involve create a certificate and put it on the hassos for allow connections on port 22222.
Really thanks for the help!

[jimklimov]

CC @frenck : a HA NUT plugin user here struggled with snmp-ups and the plugin apparently not passing the mibs setting to the driver... can you please confirm if this keyword is properly supported by the plugin?