nut icon indicating copy to clipboard operation
nut copied to clipboard

CyberPower CP1500AVRLCD3 doesn't reliably work unless NUT_DEBUG_LEVEL set

Open kenlasko opened this issue 4 months ago • 1 comments

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

kenlasko avatar Oct 09 '25 18:10 kenlasko

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?..

jimklimov avatar Oct 10 '25 03:10 jimklimov