Very occasionally I get a battery value of zero, which of course triggers the notification, and then it goes away.
Do you see a disconnect as well?
Nope. It only happens very occasionally. I just turned on debug logging, so next time it happens I will capture that.
Yup. Just got it and you are right, it also momentarily disconnected.
Here are the log entries when it happens:
2024-11-22 09:58:07.120 PMinfoconnected to upsd on 192.168.1.166:3493 - monitoring ups every 5 seconds
dev:1152024-11-22 09:58:05.977 PMinfodisconnected from upsd
dev:1152024-11-22 09:58:05.934 PMinfoupdated: ups ups on host 192.168.1.166:3493
Those log entries are the result of saving preferences for the driver. That's a purposeful event, and you should expect the driver to disconnect if it's currently connected. The driver will always attempt to establish a new connection using the newly saved preferences.
Understood. Thanks for the explanation.
just came across this and trying to use it with qnap that is connected to a UPS.
Qnap reports it. I setup qnap to act as a UPS master and allowed the IP from hubitat.
once i did this i get the following in my error logs:
dev:5732024-12-15 07:17:48.460 PMdebugparse: VAR qnapups ups.status "OL"
dev:5732024-12-15 07:17:48.453 PMdebugparse: VAR qnapups ups.load "25"
dev:5732024-12-15 07:17:48.444 PMdebugparse: VAR qnapups battery.runtime "1725"
dev:5732024-12-15 07:17:48.434 PMdebugparse: VAR qnapups battery.charge "100"
dev:5732024-12-15 07:17:48.370 PMinfodisconnected from upsd
dev:5732024-12-15 07:17:48.359 PMdebugdisconnecting from upsd...
dev:5732024-12-15 07:17:48.338 PMerrorupsd: Access denied
dev:5732024-12-15 07:17:48.334 PMdebugparse: ERR ACCESS-DENIED
dev:5732024-12-15 07:17:48.312 PMdebugparse: OK
dev:5732024-12-15 07:17:48.303 PMdebugparse: OK
dev:5732024-12-15 07:17:48.009 PMinfoconnected to upsd on 192.168.0.104:3493 - monitoring qnapups every 5 seconds
dev:5732024-12-15 07:17:47.990 PMdebugattempting to connect to upsd on 192.168.0.104:3493...
Any suggestions? looks like it is getting the info but also an access denied message
You have the wrong username/password. Last I knew, QNAP used hardcoded values of admin/123456, but you should check the upsd.users file on the server.
1 Like
thank you!! that was it
thought i needed a username from qnap.
1 Like
I needed to do some work on the circuit powering my network rack, which also provides power to the HE hubs. The power was off long enough for the NUT server to issue a forced client shutdown, and the NAS and hubs dutifully complied. However, the power was not off long enough for the UPS itself to shut down, therefore, the HE hubs never lost power and remained in whatever state of limbo they're in after doing a soft shutdown.
The only way to get the hubs running again of course was to physically remove power for a few seconds. If this had happened during the summer when we're away for several months, I'd be screwed.
I assume that if a forced shutdown is issued, the UPS should have shut down momentarily even if AC power had been restored, but if that's correct, who is at fault here? Did the NUT server not issue the command to the UPS to shut down, or did the UPS not properly respond?
I am using a Synology DS918+ as the NUT server, and a CyberPower OR500LCDRM UPS. I read the posts concerning the Synology NUT server, but I'm not sure if that applies to this situation. Here's the relevant logs from the Synology:
and from one of the hubs:
Actually, I could remotely restart one hub by cycling POE power, and I have a couple of Sonoff USB wifi switches that I could use to remotely cycle power on the other two hubs.
Or I have an unused Pi 3 that I could run a different NUT server on. But if the problem is the UPS itself, a different NUT server probably won't make any difference.
Thoughts anyone?
I don’t think anything tells the UPS to shut down, it will just run until the battery dies.
You're saying that this is expected behavior? So the NUT server tells everything to shut down but power may not actually be interrupted if power is restored before the battery dies? Then how do things that need a power cycle (like HE) restart without manual intervention?
AFAIK yes that is normal and expected. Unless there are more advanced UPS that can shut down or cycle the outlet? Maybe enterprise level. A PC or server wont start back up either without a specific bios setting and a power cycle, unless you have something send out WOL packets when power comes back. Not sure if NUT can do the WOL itself I have not looked into it. Power outage is rare for me, usually only lasts a few minutes, and we are not away from home for long periods of time.
For HE most people who are concerned about remote power cycling either have PoE power they can cycle or add a Wifi controlled smart plug so they can switch it off and on again independant of HE. TP Link is popular and now also any reliable matter plug might be good for this since it can integrate into all different systems easily.
The problem is that you are using Synology as a NUT server. Synology has modified their NUT configuration such that it goes into a quiescent state and never instructs the UPS to cut power. While this is contrary to NUT best practice, it's what they've done. I believe QNAP is now doing similar.
You can go in and rewrite the entire NUT config by hand, but it gets wiped out on with config save or OS upgrade. The only real way to fix it is to move the NUT server to another system. Raspberry Pis are a common choice.
1 Like
It's only expected behavior with Synology (and QNAP I believe). NUT itself is designed to cut power as the last step in the shutdown process on the master/primary server.
FWIW, it's generally a bad idea to use a NAS as the NUT master/primary since it takes them longer to shut down. The NUT master server should be chosen based on a combination of reliability (for which a NAS is a good choice) and speed of shutdown (for which a NAS is a very bad choice).
Ok, but if the NUT server is running on a pi, will the pi shutdown gracefully before the UPS cuts power? Seems like it could be a chicken and egg situation. Or can a UPS be told to cut power in x number of seconds, giving the NUT server itself time to shut down?
So the NAS doesn't actually shut itself off, it just puts itself in a state where a power loss isn't harmful, right? And if power comes back on it just restarts its services I suppose. Wonder why they went to that trouble.
No, and yes. 
I've written about this stuff too many times. See this post in the pfSense forum and follow the links to the two other posts that provide lots of detail on these issues.
It's a lot quicker to return the NAS to service if the UPS never actually runs out of battery. It also lessens support requests from non IT users who buy a UPS and expect it to magically work. Somewhat common with Synology/QNAP customers.
