CyberPower CP1500AVRLCD3 doesn't reliably work unless NUT_DEBUG_LEVEL set

[kenlasko]

As is apparently quite common with CyberPower UPSs, I have had a hell of a time trying to get my CyberPower UPS to reliably stay connected to NUT in a homelab Kubernetes environment. No matter what I did, the UPS would go offline within a few minutes with repeated DATA STALE errors. I tried various iterations of modifying:

• maxretry
• pollfreq
• pollinterval
• pollonly = "enabled"
• MAXAGE
• DEADTIME

Nothing seemed to work. I then tried to set debug logging through the envvar NUT_DEBUG_LEVEL=5. As soon as I set that, UPS communication worked flawlessly for the next 24h. I've since dropped the debug level to 1 and it still works. If I remove the NUT_DEBUG_LEVEL env var, the UPS reverts to its previous behaviour by going offline within a few minutes.

Curious as to why the debug setting seems to be the magic trick to get my CyberPower UPS working?

My environment is the following:

• Kubernetes 1.34.1 running on Talos Linux 1.11.2
• Using instantlinux/nut-upsd:2.8.3-r2 container
• UPS connected to Beelink mini-PC along with another Belkin UPS that has always worked fine with this implementation.

ups.conf

maxretry = 10
[belkin]
    driver = usbhid-ups
    port = auto
    vendorid = 050D
    productid = 0900
    desc = "Belkin UPS"
    pollinterval = 5

[cyberpower]
    driver = usbhid-ups
    port = auto
    vendorid = 0764
    productid = 0601
    desc="CyberPower CP1500AVRLCD3"
    pollfreq = 30
    pollinterval = 30
    pollonly = "enabled"

upsd.conf

LISTEN 0.0.0.0 3493
MAXAGE 30

upsmon.conf

MONITOR belkin@localhost 1 monitor upsmon master
MONITOR cyberpower@localhost 1 monitor upsmon master
SHUTDOWNCMD "echo 'System shutdown not configured!'"
DEADTIME 30

[jimklimov]

There was a bug (though years before 2.8.3) hit after code refactoring, where a debug message printing call was also evaluating the variable somehow (incremented it?)

So after debug messaging code was fixed to do nothing if the verbosity was not high enough, that useful code got skipped.

I really wonder if anything similar might survive unnoticed this long?..

[com6056]

I'm hitting the same issue with a CP1500PFCLCDa, thought I was going crazy 😂 If I remove NUT_DEBUG_LEVEL, it loses the connection after a couple minutes:

UPS: ups@localhost (primary) (power value 1)
Poll UPS [ups@localhost] failed - Data stale
Communications with UPS ups@localhost lost
Poll UPS [ups@localhost] failed - Data stale
Poll UPS [ups@localhost] failed - Data stale
Poll UPS [ups@localhost] failed - Data stale
Poll UPS [ups@localhost] failed - Data stale
Poll UPS [ups@localhost] failed - Data stale
Poll UPS [ups@localhost] failed - Data stale
Poll UPS [ups@localhost] failed - Data stale

I'm running NUT via https://hub.docker.com/r/instantlinux/nut-upsd:

  nut:
    image: instantlinux/nut-upsd
    container_name: nut
    environment:
      - TZ=America/Los_Angeles
      - API_PASSWORD=${NUT_API_PASSWORD}
      - NUT_DEBUG_LEVEL=1
    network_mode: host
    restart: unless-stopped
    devices:
      - /dev/bus/usb:/dev/bus/usb
    volumes:
      - ./ups.conf:/etc/nut/local/ups.conf:z,ro

ups.conf:

[ups]
  driver = usbhid-ups
  port = auto
  pollonly = true 

[com6056]

I had Claude do some digging and here's what it came up with in case it helps:

Summary

I found the issue! It's in libhid.c:

The HIDDumpTree() function has an early return when nut_debug_level < 1:

if (nut_debug_level < 1) {
    return;
}

This function is called during driver initialization to dump all HID objects for debugging purposes. However, it has an important side effect: it calls HIDGetDataValue() on all HID items (line 456), which causes the driver to fetch fresh data from the device for each report.

Why this matters:

When NUT_DEBUG_LEVEL is NOT set:

• HIDDumpTree() returns early without fetching any data
• Initial report buffers may not be properly populated
• The polling mechanism might be working with stale/uninitialized report cache
• Connection appears to fail with "Data stale" errors

When NUT_DEBUG_LEVEL IS set (even to 1):

• HIDDumpTree() proceeds and fetches all HID data during initialization
• This populates the report buffer cache (reportbuf) with valid data
• Subsequent polling operations work correctly because the cache is properly initialized
• Connection remains stable

The real bug is that the driver relies on the side effect of debug-only code to properly initialize its internal state. The report buffer should be initialized regardless of debug level.

Recommended fix: The initialization logic should ensure all necessary HID reports are fetched at least once during startup, independent of the debug level. The data fetching in HIDDumpTree() should not be the only place where initial report population happens.

This explains why both you and the original reporter see the exact same symptom: the UPS works perfectly with NUT_DEBUG_LEVEL=1 but fails without it.

[com6056]

Alright I think #3259 is actually the fix, it was running for a while for me without disconnects 🎉

I did some cleanup to my changes, now I'm testing again to make sure it still works. Also trying to see if I can also remove pollonly = true with this change 🤞

Will update in a couple days with my testing results!

[com6056]

So far so good, been running without pollonly = true for 35+ hours now with no disconnects 🎉