Skip to content

Support request: Ever (Phoenixtec) PowerLine RT Pro 3000 SNMP sysOID .1.3.6.1.4.1.935.10.1 #3088

Open

Description

@azael-azael

Device information

  • Vendor/Brand: Ever (Phoenixtec)
  • Model: PowerLine RT Pro 3000
  • Interface: NMC (SNMP v3)
  • NMC firmware version: [please fill in from web GUI]
  • sysOID: .1.3.6.1.4.1.935.10.1

NUT information

  • NUT version: 2.8.0
  • Driver: snmp-ups
  • OS/Distribution: Debian 12

Problem description

When starting the snmp-ups driver, the following message is displayed:
No matching MIB found for sysOID '.1.3.6.1.4.1.935.10.1'!

Please report it to NUT developers, with an 'upsc' output for your device.
Going back to the classic MIB detection method.

Despite this, the UPS works with mibs = auto or mibs = ietf.
Instant commands supported are limited (load.off/on, beeper control, battery tests), but there is no per-outlet control.

ups.conf:
[ups01-snmp]
driver = snmp-ups
port = 192.168.1.244
# SNMPv3
snmp_version = v3
secLevel = authPriv
secName = xxx
authProtocol = MD5
authPassword = xxxx
privProtocol = DES
privPassword = xxxxx
mibs = auto
pollfreq = 5
desc = "Ever PowerLine RT Pro 3k + NMC (SNMPv3)"

Full upsc output

upsc ups01-snmp@localhost:
Init SSL without certificate database
battery.charge: 100
battery.current: -0.10
battery.runtime: 59940
battery.runtime.low: 0
battery.temperature: 20
battery.voltage: 80.10
device.contact: Technical Support Center
device.description: Network Management Card for UPS
device.location: B1-S1-SS2
device.mfr: EPPC
device.model: ON-LINE
device.type: ups
driver.name: snmp-ups
driver.parameter.authProtocol: MD5
driver.parameter.mibs: auto
driver.parameter.pollfreq: 5
driver.parameter.pollinterval: 2
driver.parameter.port: 192.168.1.244
driver.parameter.privProtocol: DES
driver.parameter.secLevel: authPriv
driver.parameter.snmp_version: v3
driver.parameter.synchronous: auto
driver.version: 2.8.0
driver.version.data: tripplite MIB 1.54
driver.version.internal: 1.21
input.bypass.frequency: -0.10
input.bypass.phases: -1
input.current: -0.10
input.frequency: 50
input.frequency.nominal: 50
input.phases: 1
input.realpower: -1
input.transfer.high: 0
input.transfer.low: 0
input.voltage: 236
input.voltage.nominal: 230
output.current: 0
output.frequency: 50
output.frequency.nominal: -0.10
output.phases: 1
output.power.nominal: -1
output.realpower: 0
output.realpower.nominal: -1
output.voltage: 230
output.voltage.nominal: -1
ups.beeper.status: disabled
ups.firmware: 02.14
ups.firmware.aux: 3.6.0.1
ups.load: 0
ups.mfr: EPPC
ups.model: ON-LINE
ups.status: OL
ups.test.result: done and passed
ups.timer.shutdown: -1
ups.timer.start: -1

Steps to reproduce

  1. Configure ups.conf with:
    [tups01-snmp]
      driver = snmp-ups
      port = 192.168.x.x
      snmp_version = v3
      secLevel     = authPriv
      secName      = zbxups
      authProtocol = MD5
      authPassword = ****
      privProtocol = DES
      privPassword = ****
      mibs = auto

Run upsdrvctl start.

See the sysOID detection warning in logs.

Requested:
Add recognition of sysOID .1.3.6.1.4.1.935.10.1 (Ever / Phoenixtec PowerLine RT Pro 3000) to snmp-ups.
Confirm whether vendor-specific outlet control is available through this NMC.

Additional notes
There are two identical units with the same sysOID and behavior.
SNMPv3 authPriv (MD5/DES) is required by the environment.
If needed I can provide full SNMP walk of .1.3.6.1.2.1.33 and .1.3.6.1.4.1.935 branches.

Thank you!

Activity

  1. added
    Phoenixtec (USB 0x06DA/0xFFFF)This USB chip VID/PID is used in many devices, some with different protocols - detection may be hard
    impacts-release-2.8.0Issues reported against NUT release 2.8.0 (maybe vanilla or with minor packaging tweaks)
    on Sep 12, 2025
  2. jimklimov commented on Sep 12, 2025

    @jimklimov
    Member

    Hello, please note that like much other FOSS, this is a volunteer-supported open source project, done in spare time for fun or to scratch one's own itch. Personally, I can't commit to making the requested changes, but can offer some pointers how you or someone else could do them (SNMP walks would be helpful in either case):

    • See the NUT Developer Guide in general, and particularly https://networkupstools.org/docs/developer-guide.chunked/new-drivers.html#snmp-subdrivers about generating a new subdriver. In your case, only the IETF one matched for industry-standard data points (says Tripplite but it is aliased to IETF), so to map vendor extensions like the concept of numbered outlet lists you would need a new dedicated subdriver. For practical examples, see APC, Baytech, Compaq, Eaton/MGE, HPE, Raritan sources (drivers/*-mib.c) for examples that have something.%i.something in the NUT datapoint names, where the %i is automatically substituted for numbered outlet, sensor, etc. number.
    • Speaking of NUT names, please see the section starting at https://networkupstools.org/docs/developer-guide.chunked/nut-names.html (and several next-next-next pages from there) or https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt about already standardized concepts - try to fit into those, and so avoid surprise for clients expecting them and not other strings.
    • See https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests about custom-building NUT from a git workspace (which you would initially seed from here, and then modify with code generated and edited per above). To test the results, you can run the driver program in data-dump mode right from the build workspace (do not have to set up the whole stack of NUT services) - and being an SNMP client, you can do this on whichever system has the needed network access and is comfortable for you to work in. Can well be a Linux VM (including a WSL one) or LXC container. Can be TermUX on your Android phone (can't say that one would be comfortable to edit code, though).
  3. azael-azael commented on Sep 13, 2025

    @azael-azael
    Author

    Thank you for answer.
    Additional informations:

    On mibs=auto I repeatedly get:
    No matching MIB found for sysOID '.1.3.6.1.4.1.935.10.1'! Going back to the classic MIB detection method.
    Detected ON-LINE on host 192.168.1.244 (mib: tripplite 1.54)
    [tups06-snmp] unhandled ASN 0x81 received from 1.3.6.1.2.1.33....
    [tups06-snmp] unhandled ASN 0x80 received from 1.3.6.1.2.1.33....

    With mibs=ietf the device works; the “unhandled ASN …” lines still appear for non-implemented optional UPS-MIB entries, but functionality is OK.

    SNMP proof (vendor EPPC-MIB)

    sysDescr / sysObjectID:
    1.3.6.1.2.1.1.1.0 = "Network Management Card for UPS"
    1.3.6.1.2.1.1.2.0 = .1.3.6.1.4.1.935.10.1

    Segment 1 state (works) and Segment 2 (not supported on this unit):
    .1.3.6.1.4.1.935.10.1.1.5.5.0 = 2 # upsELoadSegment1State = on(2)
    .1.3.6.1.4.1.935.10.1.1.5.10.0 = 5 # upsELoadSegment2State = not-support(5)

    Segment 1 control (used successfully in production):
    OFF now: .1.3.6.1.4.1.935.10.1.1.5.1.0 i 0 (upsELoadSegment1OffDelay = 0)
    ON now: .1.3.6.1.4.1.935.10.1.1.5.2.0 i 0 (upsELoadSegment1OnDelay = 0)
    Semantics: INTEGER -1..32767 (0=immediate, -1=cancel, >0 seconds)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    DDLHCLPhoenixtec (USB 0x06DA/0xFFFF)This USB chip VID/PID is used in many devices, some with different protocols - detection may be hardSNMPdocumentationimpacts-release-2.8.0Issues reported against NUT release 2.8.0 (maybe vanilla or with minor packaging tweaks)

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions