CyberPower CP1500AVRLCD3 doesn't reliably work unless NUT_DEBUG_LEVEL set
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-r2container - 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
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?..