Rysz

No, shows just fine here - perhaps you were looking for an older and deprecated version? The only currently and actively maintained one is by me (Rysz).

Can you try changing the NUT backend to "release (2.8.0 stable)" and see if that works? In NUT Settings using the "Network UPS Tools Backend Switch" (need to reboot after switching). If that doesn't work you can also try the oldest backend "legacy (2.7.4. stable)". Please let me know if any of those suggestions worked for you!

That's what I meant, you can create a seperate .page file in your plugin for this, specifically by using the "Buttons" menu your hidden code will be available on all GUI pages. Then you can use PHP to make sure it is included only on the "Main" page where it is needed. Using JS you could then communicate with (for example) a PHP script of your plugin that returns the parity check status, afterwards parsing that result and then using jQuery to enable/disable the respective buttons on the fly. That checking function could be run periodically using a timer, say every 5 seconds or whatever time you set. There's no real need to cause a full page refresh, you could just update the relevant parts using jQuery. Here's an example .page file that would achieve such a hidden code insertion: Menu="Buttons:198" Link="nav-user" --- <?if(stripos($path, "main") !== false):?> <script type="text/javascript"> // this section gets added to all GUI pages where path has 'main' in the URL // could check for parity check status here, e.g. communicating with PHP script // or checking for file existence. could parse result and enable/disable parity // buttons using jQuery afterwards. a timer could run check function periodically. </script> <?endif;?>

Why not do it via .page and JS, periodically checking the status of the parity operation and enabling/disabling buttons accordingly? There'd be no need to do a full page refresh with JS checking the parity operation's status and then enabling/disabling buttons via jQuery.

Then it's probably just reported wrongly by the driver, if the beeper is otherwise working that's the most important thing.

Can you try beeper.on instead of beeper.enable?

Did you enable ModBus on the UPS itself? It needs to be specifically enabled on the hardware and particularly if the regular USB driver works for you that seems to me a sign that ModBus is not enabled on your UPS.

It seems APCUPSD development has been stale for a couple of years now, so wouldn't expect much there. In the meantime it seems the NUT ModBus implementation seems to work (see above), so might be worth testing that.

Since your UPS doesn't provide the actual power draw it's calculated from the load and nominal power (wrongly 388W). There's a setting in the GUI: "UPS Power and Load Display Settings" where you can override the wrongly reported nominal power values ("Manual"). You should put your actual values 1500VA/900W there and it'll then show the correct power draw in the GUI. Please let me know if that worked for you!

Of course, just set "Start Network UPS Tools Service" to "Yes" and click on "Apply". If it is currently set to "Yes": Set it to "No" -> Click "Apply" -> Set it to "Yes" -> Click "Apply". Please let me know if that worked for you 🙂

Looking good, make sure to connect the UPS to your UNRAID (e.g. via USB) using the inbuilt "UPS Settings" (apcupsd) or the NUT plugin. This'll ensure you'll have graceful shutdowns when the power goes out. Some people also had their HBA cards run extremely hot and strapped a small fan to them. This of course depends on the airflow situation in your case, just something to watch out for in case of problems. 🙂

Cheers, I think this is what I'll do (more of the manual type) - thanks again!

Just to be clear, this would require me to update to 6.12.x and then a factory reset using that, right? 🙂

Hello experts! I have a really old UNRAID backup server running 6.8.3. which has never given me any trouble so far. As that version is so outdated I'd like to finally migrate to 6.12.x BUT preferably with a new installation of UNRAID rather doing the large step updating from 6.8.3 to 6.12.x Is there a way to start over with a fresh installation of UNRAID while preserving both parity and data on my current drives (meaning no rebuilds or parity-sync)? Essentially I would like to tell the new installation here's 2 parity and 6 data drives, parity and data is intact so please use that and don't do anything to my drives. 😄 Any pointers in the right direction would be much appreciated! 😉

Did you make any significant changes to the UPS (battery/settings), the physical connection (different USB cable/port) or NUT (changed backend/updated from much older version) recently that could correlate with this issue? If it worked well before then it looks to me like the USB cable or USB port is dying, hopefully not the USB interface on the USB itself. Can you try with another USB cable or USB port and check if the problem resolves? Configuration-wise everything looks good, so I'm thinking it's something with the physical connection that causes these dropouts - especially since the UPS is recognized at first.

Exactly, and there's not really all that much runtime on most UPS to do fine-grained selective service shutdowns. Important is that everything is gracefully shutdown as intended by UNRAID, which is why the inbuilt graceful shutdown mechanism is used here.

Did you change anything before this stopped working (UPS firmware update, used another USB port or hub, updated from a much older NUT version, changed the NUT backend, ...)? It looks like the UPS either cannot read, estimate or send the runtime information anymore, because NUT itself receives "battery.runtime: 0" from the UPS. Is the battery you changed to new and properly connected inside the UPS, are there any LED indications that something is not working as it should? Another thing you could try is if the runtime is shown when you disable NUT and use the inbuilt APCUPSD service's "UPS Settings" in UNRAID (just for testing), this way we could better determine if this is a software (NUT/NUT driver) or hardware (UPS/UPS connectivity) problem.

Hmm, I'm afraid I'm out of my depth with this now. In this case it's probably best to keep those lines then, if the UPS doesn't function otherwise. You could open an issue on GitHub hoping that the NUT driver developers might be able to help you tune your settings some more: https://github.com/networkupstools/nut/issues I'm sorry that I couldn't be of more help here!

I see you're using these UPS.CONF settings in your old post: default.battery.voltage.high = 27.50 default.battery.voltage.low = 21.40 default.battery.voltage.nominal = 24.00 If you do this then the driver will guess the battery charge based on the battery voltage. Particularly older batteries cannot hold their maximum voltage well anymore and have sags in voltage (possibly causing frequent re-charges). It's possible this mechanism causes your battery to look as "charging" when fluctuations or changes in voltage occur. It's also possible that when the UPS sees an increased load when you start up your server it'll start topping up the battery from a lower voltage to a higher voltage (to ensure providing as much battery time as possible), as opposed to times when the UPS load is minimal and the battery can rest with a lower voltage. Normally the UPS itself provides information about the battery charge, so these settings are not needed and the charge provided is an estimation at best. Please try removing these settings from the UPS.CONF and see if the UPS then provides the actual and not voltage-based estimation of the UPS battery charge. This is in part related to what this user was warning about here in the old topic:

Yes, this is the setting you'll want. By default NUT initiates a graceful stopping of all services and disks before shutdown. Only if you have a lot of services you might need to increase/fine-tune the shutdown timeout setting under Unraid's Disk Settings to give the OS enough time to stop everything gracefully before it proceeds with the shutdown sequence anyway. A too low shutdown timeout can result in a hard shutdown if the services take longer to stop than the timeout is set, though I'd say this rarely happens with normal use cases.

I've just pushed the update including more event hooks, check out "array_start_complete.sh". Please test and let me know if that works for your use case, this should run after everything else is done. 🙂 Make sure to delete your previous code from the other script ("array_start.sh") so your array startup doesn't hang as before.

In this case it's probably better to use the "User Scripts" plugin and hook into a different array event where both the array and Docker are started already. array_start.sh is just a simple helper script that hooks into the specific event where the disks are mounted (but nothing else is started yet). The reason is because in most cases users probably want their mergerFS filesystem to be up before the other services are starting (and depending on it being there) and not the other way around. So in your case: "User Scripts" plugin would be a better choice. 🙂

Does the UPS itself show as 100% charge (on the UPS display/LEDs) when this happens or does it show any indication that it's maybe really charging the battery? This is very very weird, especially that it "charges itself up" over time is usually really only seen when the UPS is in fact charging the battery somehow. I can't picture any programmatic problem that would make the driver increase the charge from 0% to 100% over time unless that's what the UPS also does... 😕

Regarding the NUT Statistics Module, it'll also include stale data for a time-point if no new data is available at the time of querying. By your logs everything seems to work as it should NUT-wise, so it'll likely be a problem with HA's data retention and/or polling frequency. I have no idea about APCUPSD as I've never used it myself, but it likely doesn't get updated as often as NUT so maybe it's a protocol-related bug there. I use this quite successfully for monitoring NUT on my PRTG server, maybe there's also a JSON parser option within HA?: https://github.com/dietah/nut-http

In the NUT Settings you can raise the "UPS Driver Debug Level" setting to see what's going on in the suspected stale times. Would be interesting to see what the driver is doing between the updates, raising the debug level should bring this clarity. 🙂