battery.voltage not supported by Synology DS923+

[iGPtee]

It seems like battery.voltage is not supported by the DS923+ Nut Server. This line is from the WinNUT log:

[10] 29.03.2024 10:16:16 Uhr [8144, UPS_Device]: battery.voltage is not supported by server.

I'm not yet sure it has consequences for shutting down all the clients properly, Windows reports an unexpected shutdown after all.
The WinNUT Client GUI also doesn't show any value for Battery Voltage (lower right):

Can you implement alternative methods to call battery.voltage for this model? The UPS used here is an Eaton Ellipse Pro 650 DIN (USB). The Synology's DSM is up to date (7.2b3). WinNUT is v2.3.8824.

And since I'm on it ... the options input for Refresh Interval here is kinda messed up. Valid input should be something between 1 to 60, but accepted intputs range from 100 to 60000. Entering 99 or 60001 will return a red marked field.

[iGPtee]

Just updated to v2.3.8834, still see the same issues.

[TigraTT]

sorry for not beeing online for a longer time. Live sometimes is not easy........

i have the same issue with no bat voltage and also no input voltage with 2.3.8892.21649
As far as i remember it worked before wit older versions.

QNAP NAS and Eaton Eclipse ECO 650

but i did not have any input voltage since the first steps a few years ago, maybe the ECO did not provide this information?

[gbakeman]

@TigraTT No worries, I understand 😊

Please provide the output from File -> UPS Variables and let's see what the NUT server is sending you.

[TigraTT]

OK; i may understand the problem.
battery only provides charge, charge low, runtime and type. There is no Voltage.
even there is no input voltage only high (264) and low (184) are received, but no transfer voltage.

So i think that the ECO or the QNAP did not provide all values.

[gbakeman]

@TigraTT

OK; i may understand the problem. battery only provides charge, charge low, runtime and type. There is no Voltage. even there is no input voltage only high (264) and low (184) are received, but no transfer voltage.

So i think that the ECO or the QNAP did not provide all values.

I agree, definitely seems like more info ought to be available. If you have some way to install another NUT server, I'd recommend finding a way to connect your UPS with a build of NUT/upsd that's closer to the original since I've seen device manufacturers make some customizations to their distributions. Probably a newer or more accurate UPS driver available to you, or at least you'd be better equipped to troubleshoot the NUT server. I'm looking for your particular UPS in the Device Dumps Library and not seeing it exactly, so if you do end up getting another NUT server going and you still don't have better results, it would help the NUT project if you could submit your own device dump. Let me know if you have any other questions!

[A-Dunois]

Hello, trying v2.2.8719 ?
I have the same nas and an another eaton, it's seem ok.

But with v2.3.8834:

Synology DS923+ DSM 7.2.1-69057 Update 4
EATON Ellipse pro 1600 (FR)

[gbakeman]

Hi all,

Sorry for the sudden issues and for my delay in getting back to you.

I want to link to #136 since these seem fairly similar. Previously, if a variable was unavailable, WinNUT used to set it to a value that appeared real (12 volts for the battery I think). I changed that so the value is set to an out of range one, although it's discovered that the gauges will clamp themselves at the minimum value instead. In the background though, the variable is still -1 to indicate to WinNUT that it is unavailable.

@iGPtee

I'm not yet sure it has consequences for shutting down all the clients properly, Windows reports an unexpected shutdown after all.

Is there any chance you have the WinNUT logs from around this time? There would also be a line that says:

Battery properties unavailable, unable to validate shutdown conditions.

Which was something I added at the same time, as I realized that WinNUT would have always been unable to judge when it was time to shutdown based on battery variables from the NUT server, but only if those variables are missing. If you don't see that line, then it means WinNUT still has good variables to measure for a shutdown condition. Specifically, those are either the Battery charge or Battery runtime variables. Please provide the output for File -> UPS Variables and we can see if there's any suitable replacement for battery voltage.

And since I'm on it ... the options input for Refresh Interval here is kinda messed up. Valid input should be something between 1 to 60, but accepted intputs range from 100 to 60000. Entering 99 or 60001 will return a red marked field.

That one is definitely on me. The background timer in WinNUT has always taken milliseconds as a time interval, and I think WinNUT may have stored it that way too. However, it used to be converted to seconds in the preferences window. When I moved us over to the new Settings system, I standardized the time interval setting on milliseconds and updated the English translation. I forgot to clear out the old translations for that though, so it probably still says seconds instead of milliseconds. Would you prefer if the setting took seconds over milliseconds? Either way, I'll make sure the information is consistent.

[iGPtee]

Sorry for late reply here either. Finally found the time for some more testing and to tell it short ... the results are rather confusing.

First point: The WinNut Log is said to be saved in the installation folder, but I can't find it there. Instead it's located in my Windows profile \AppData\Roaming\NUTDotNet\WinNUT Client[version]. It's been kinda hard to find because there also is \AppData\Roaming\WinNUT-Client containing an empty log from the initial installation date. Would be great to have a choice in the settings to set (and recover) the log file path there. I actually don't remember whether the installer provides a choice of "install for everyone" and "user only" and what's been my choice there just in case.

Second point, about the test results: I did 3 test runs.

The first did not deliver clear results with the Synology set to enter standby at low battery, so I set the Synology to enter standby after 5 minutes of battery power for the second test, the VMs to shutdown via WinNut at 75% battery and the monitoring PC to shut down via WinNut at 30% battery.
The VMs were shut down after a minute by the Synology instead of WinNut at approx. 85% (RDP connection closed, status in Synology's VM Manager "shut down"). Shortly after that most of the services at the Synology were shut down either. I did not exactly recognize the Synology entering standby after the set 5 minutes, but after power was restored the Synology did a full reboot back into normal mode (you can hear that by sound of the HDDs). No warnings about unexpected shutdown on the Synology afterwards.

For the third test no change to the configs. Again after a minute, the VMs were "disconnected" (instead of "shut down") in VMM and then - even before the Synology quit all services - the Synology issued a warning about low battery power, and a few seconds later the Synology as well as the monitoring PC were shut down simultaneously - obviously due to power loss. After power was restored the Synology booted automatically and started Data scrubbing for the volumes (which it only does after non-regular system events). The battery charge according to WinNut at that time was still 68% ... far from being "low".

What I think is, that installing the WinNut Client on the VMs on the Synology doesn't make much sense, because the Synology shuts them down after a minute anyway to save energy - although there is no configuration or other indication for which services are shut down at which time or whether this is to happen at all. I only can tell from the behaviour above.

The unexpected shutdown during the third test can have several reasons. I think the most likely one is that the battery voltage (which is not reported to WinNut by the server) is no longer high enough to deliver the required minimum voltage to the power units of the PC and Synology when battery charge drops below 68%. Another reason might be that battery charge is not reported properly to WinNut by the server - or misinterpreted by WinNut. The same goes for Battery runtime, which seems to be calculated without looking at voltage.

After all I definitely agree with your policy in regards of Fallback Values ... removing the display of fake values in case the server does not report any values at least helps to see that something does not work properly or is not compatible.

That line you mentioned ...
"Battery properties unavailable, unable to validate shutdown conditions."
... is not in the log. The log is from the monitoring PC. But as you can see above the shutdown of that machine via WinNut wasn't tested yet. I'll focus on that point next time. Need to recover battery charge for now.

About the Refresh Timer question ... I'm a human. I'd definitly prefer seconds over miliseconds in the settings xD.
And about the logs ... I can't get useful logs from the VMs because of the 200 events limit. Can you provide a setting for that as well? Probably not even bound to events, but to time frame, or let's say a "start logging now" + "stop logging now".
Same goes for the Shutdown options. The Synology options include "at low voltage" (whatever that means) and "after x seconds/minutes/hours". Would be great to have the same choices, especailly the latter, in WinNut. Now I only have "x seconds/minutes/hours before low power" and that is hard to sync with the Synology's options. When instead you can set WinNut to shut down the client host after 3 minutes and the Synology is configured to shut down after 5 minutes timing is much easier to set up.

WinNUT-Client-2024-05-05.log
PC USV Variables.txt

[gbakeman]

No worries at all, thanks for taking your time to go through the tests and write out your thoughts here.

First point: The WinNut Log is said to be saved in the installation folder, but I can't find it there. Instead it's located in my Windows profile \AppData\Roaming\NUTDotNet\WinNUT Client[version]. It's been kinda hard to find because there also is \AppData\Roaming\WinNUT-Client containing an empty log from the initial installation date. Would be great to have a choice in the settings to set (and recover) the log file path there. I actually don't remember whether the installer provides a choice of "install for everyone" and "user only" and what's been my choice there just in case.

I think you found an outdated string that I just corrected! Logging was a little broken recently in WinNUT, and this was fixed in #142 so you may need to update to the latest pre-release to correct any oddities you may have seen with log files. In addition, I've been trying to standardize the way WinNUT uses file storage in Windows to bring it inline with .NET Framework standards, and that means it will automatically pick the path of (organization)\(program name-version). You can safely delete AppData\Roaming\WinNUT-Client as that was an older, manually defined path. We do have a shortcut to open the log file directly if that helps (see screenshot below, it's the icon of a file with the 'i' on it.) Would it help if I also added a shortcut to the Logs folder, or would you prefer being able to manually specify log location entirely? As far as the installer installing for Everyone/current user, I think you're right in that it does provide the option - but as far as I can remember, it doesn't change anything. I'm working on moving us to a new installer system in #97 if you want to follow along there, since the current installer system is outdated and not very well supported.

Second point, about the test results: I did 3 test runs.

The first did not deliver clear results with the Synology set to enter standby at low battery, so I set the Synology to enter standby after 5 minutes of battery power for the second test, the VMs to shutdown via WinNut at 75% battery and the monitoring PC to shut down via WinNut at 30% battery. The VMs were shut down after a minute by the Synology instead of WinNut at approx. 85% (RDP connection closed, status in Synology's VM Manager "shut down"). Shortly after that most of the services at the Synology were shut down either. I did not exactly recognize the Synology entering standby after the set 5 minutes, but after power was restored the Synology did a full reboot back into normal mode (you can hear that by sound of the HDDs). No warnings about unexpected shutdown on the Synology afterwards.

For the third test no change to the configs. Again after a minute, the VMs were "disconnected" (instead of "shut down") in VMM and then - even before the Synology quit all services - the Synology issued a warning about low battery power, and a few seconds later the Synology as well as the monitoring PC were shut down simultaneously - obviously due to power loss. After power was restored the Synology booted automatically and started Data scrubbing for the volumes (which it only does after non-regular system events). The battery charge according to WinNut at that time was still 68% ... far from being "low".

What I think is, that installing the WinNut Client on the VMs on the Synology doesn't make much sense, because the Synology shuts them down after a minute anyway to save energy - although there is no configuration or other indication for which services are shut down at which time or whether this is to happen at all. I only can tell from the behaviour above.

The unexpected shutdown during the third test can have several reasons. I think the most likely one is that the battery voltage (which is not reported to WinNut by the server) is no longer high enough to deliver the required minimum voltage to the power units of the PC and Synology when battery charge drops below 68%. Another reason might be that battery charge is not reported properly to WinNut by the server - or misinterpreted by WinNut. The same goes for Battery runtime, which seems to be calculated without looking at voltage.

Thanks for doing these tests! I think it's interesting you've found that Synology must be doing some sort of automatic service management which includes shutting down virtual machines, and somehow it doesn't let you configure this. Can you confirm if the Synology is actually hard-powering off your VMs, or is it suspending them or gracefully shutting them down? I've tried to have my Synology do it's low power/suspend mode, but for me it just leaves the HDDs spinning and draining more power from my UPS so instead I just shut it down once I've been on battery for longer than five seconds. I think you're right in that it may not make much sense to have WinNUT running as a client inside the VMs to self-manage them... ideally, the Synology should coordinate that but it's unclear how that's working. I think you also correctly nailed the reason for the unexpected power off - it may just be that the UPS battery is a little weak or out of calibration, so it's not behaving how the UPS or NUT server is expecting it to. If you want to do a "sanity check" test, you may want to set the Shutdown if battery lower than % setting to something like 99% or 98%, then make sure the VM will gracefully shutdown when WinNUT tells it to.

After all I definitely agree with your policy in regards of Fallback Values ... removing the display of fake values in case the server does not report any values at least helps to see that something does not work properly or is not compatible.

That line you mentioned ... "Battery properties unavailable, unable to validate shutdown conditions." ... is not in the log. The log is from the monitoring PC. But as you can see above the shutdown of that machine via WinNut wasn't tested yet. I'll focus on that point next time. Need to recover battery charge for now.

After looking at your UPS values, it does indeed look like that, between the UPS and NUT server, the battery voltage is not being reported so that's why your gauge isn't working. However, the battery charge percent and estimated runtime are reported so WinNUT should still be able to determine a shutdown condition on those alone.

About the Refresh Timer question ... I'm a human. I'd definitly prefer seconds over miliseconds in the settings xD.

Haha, of course! ☺️ I've just opened a new issue in #153 if you want to track the progress of fixing that.

And about the logs ... I can't get useful logs from the VMs because of the 200 events limit. Can you provide a setting for that as well? Probably not even bound to events, but to time frame, or let's say a "start logging now" + "stop logging now". Same goes for the Shutdown options. The Synology options include "at low voltage" (whatever that means) and "after x seconds/minutes/hours". Would be great to have the same choices, especailly the latter, in WinNut. Now I only have "x seconds/minutes/hours before low power" and that is hard to sync with the Synology's options. When instead you can set WinNut to shut down the client host after 3 minutes and the Synology is configured to shut down after 5 minutes timing is much easier to set up.

Regarding the logs, I've generally intended for those to be enabled and running constantly. If the user has Create LogFile disabled in their options, then WinNUT will still buffer log events in memory. So if the user enables the log file option at some point during the program's operation, it will dump that buffer into the log file before everything is synced and logging consistently. You shouldn't see that "Displaying last 200 events" message unless you enabled the log to file option while WinNUT is running. I'd recommend you leave the log file option on and set to Debug logging level at least while we're troubleshooting issues. Do you still feel there's a benefit to the time frame-based logging idea you were suggesting earlier?

As far as shutting down... I believe the "at low voltage" is coordinated with the battery.charge.low variable reported by the NUT server. I think this value is set either on the UPS firmware, or somewhere within the NUT server its self (and may even be user-configurable) just as a way to coordinate other functions the server provides. It would be a good idea for WinNUT to allow the user to track this setting. I think I also see what you mean by having some sort of option that allows you to shutdown after a specified amount of time on battery power. I've been using a workaround myself, which is that I set the battery percentage condition to something like 95 or 100% (with runtime zeroed out, and Immediate stop action unchecked), then I set the Delay to Shutdown (sec) value to however long I want WinNUT to wait before shutting down. That way, if power comes back on, the shutdown timer is cancelled and everything returns to normal. But I definitely can see how it would be nice to have a "Perform stop action after being on battery for x amount of time". I also have #92 open where I'm planning on some sort of configurable actions system that will allow the user to specify actions that they want to be performed when certain conditions on meant, and I've just updated it now so I remember to consider this idea.

Thanks again for all of your input. Let me know if I've missed anything of your have more thoughts on this.