SOLVED Setting up APC UPS

[Harsesis]

Hi,

I just grabed myself a new APC UPS (1500RMI) and I successfully connected it to a server running new newest freenas version using USB (will try to grab a network management card in future). I can use upsc to get the current status of the UPS.

I just played with the configs and I set the overwrite function to set the battery.charge.low and battery.runtime.low values to 80 and 9000 (just for testing the shutdown on low battery without draining the whole battery). Afterwards I let the server run on battery and the bat droped below the 80% but the server did not shutdown.

Does one of you have any ideas what is wrong with my setup?

 

[Bidule0hm]

How did you configure the UPS service?

 

[Harsesis]

Wow, that was a quick response @Bidule0hm! Take a look at the attached screenshot for my configuration:

 

[Bidule0hm]

Should be ok.

Maybe the override doesn't work.

 

[Harsesis]

Hmm i thougth the same, but at least upsc does report back the correct (overwritten) value for the battery.charge.low value. Is there another way of settings the value? The current server is only drawing arround 40W, so I did not had the patience to wait for it to reach 10% battery charge. Otherwise I would prefere changing the value anyway to give me a bit more headroom for shutdown with my "production" server.

Is there anything I can try?

 

[rogerh]

I am talking from memory here, so this may be rubbish. However, my recollection from the NUT homepage is that the 'override' parameters only change what the driver reports, not the settings on the UPS. (There must presumably be a use for this!) In which case you would have to use apcupsd on a linux or 'BSD box to set them, or APC proprietary software (used to be Powerchute Plus?) probably on a Windows box. Fortunately I think they are persistent. Though possibly not if you reset the UPS or change the battery.

However, FWIW, you can set 'ondelay' and 'offdelay' if you want to, through the dialogue box you used above and this does work at leas on my old SmartUPS.

 

[Harsesis]

Thanks @rogerh! I just did some more research on the overwriting and found out that I have to set the "ignorelb" flag as well. When this flag is set the driver ignores the "lowbat" status of the UPS and just uses the battery.charge and battery.charg.low values to determine when it should shutdown! After settings this flag the shutdown worked without any trouble!

My config now looks like:

Code:

ignorelb
override.battery.charge.low = 20

 

[rogerh]

Thanks @rogerh! I just did some more research on the overwriting and found out that I have to set the "ignorelb" flag as well. When this flag is set the driver ignores the "lowbat" status of the UPS and just uses the battery.charge and battery.charg.low values to determine when it should shutdown! After settings this flag the shutdown worked without any trouble!

My config now looks like:

Code:

ignorelb
override.battery.charge.low = 20

Glad you worked it out. Clearly it is more complicated than I thought. I actually shutdown using the time on battery, so never looked into it properly.

 

[Harsesis]

With "time on battery" you mean how long the server is already running on battery (option "shutdown timer" in the menu) or do you mean the remaining battery runtime, that is reported by the ups?

 

[rogerh]

With "time on battery" you mean how long the server is already running on battery (option "shutdown timer" in the menu) or do you mean the remaining battery runtime, that is reported by the ups?

I mean the shutdown timer. But I don't do that in FreeNAS, because the FreeNAS implementation is broken.[1] I run FreeNAS as a NUT slave to a linux machine running NUT.

[1] https://bugs.freenas.org/issues/5913

 

[Bidule0hm]

But I don't do that in FreeNAS, because the FreeNAS implementation is broken.

Wait, this problem exists since 9.2 and it's not fixed in 9.3? Seriously, it's just 3 chars in a file, I fixed it myself (FINALDELAY 10 instead of FINALDELAY ${ups_shutdowntimer}) but it's so annoying to fix it after each update. What's hard in doing this fix?

 

[rogerh]

Wait, this problem exists since 9.2 and it's not fixed in 9.3? Seriously, it's just 3 chars in a file, I fixed it myself (FINALDELAY 10 instead of FINALDELAY ${ups_shutdowntimer}) but it's so annoying to fix it after each update. What's hard in doing this fix?

You may notice it is marked 'Not to be Fixed'! All is not lost, as one of several duplicates of it has been transferred to 10 and is marked with some fairly high priority.

 

[Bidule0hm]

Yeah, saw it's to be fixed in the 10 version but it's just a big shame it hasn't be fixed already, devs: you're doing it wrong. It's very important because for example if your UPS has a runtime of 15 min and you set the delay to 10 min so you think it's safe because you have a margin of 5 min, but the system will take 20 min before it shutdowns but your UPS will cut out way before that...

 

[rogerh]

Yeah, saw it's to be fixed in the 10 version but it's just a big shame it hasn't be fixed already, devs: you're doing it wrong. It's very important because for example if your UPS has a runtime of 15 min and you set the delay to 10 min so you think it's safe because you have a margin of 5 min, but the system will take 20 min before it shutdowns but your UPS will cut out way before that...

It's worse than that! If you set a 10min delay and then change your mind and configure the NUT GUI tab for shutdown on low battery it will add a FINALDELAY of 10 minutes after you reach the low battery condition before shutting down. There is an easy workaround if you know about the bug, but you are unlikely to use it if you don't!

 

[Bidule0hm]

Oh god... It's just unacceptable

There's just no excuse, at all, to not have fixed this bug right in the 9.2, let alone the 9.3...

 

[rogerh]

Oh god... It's just unacceptable

There's just no excuse, at all, to not have fixed this bug right in the 9.2, let alone the 9.3...

I guess the the decision-makers have taken the position that UPS control is a very peripheral function they don't want to spend a lot of development time on, and therefore no-one has actually looked and noticed that the only problem was that they should have left FINALDELAY completely alone. Your fix sounds pretty watertight, I don't see how it can affect anything else.

 

[rogerh]

I guess the the decision-makers have taken the position that UPS control is a very peripheral function they don't want to spend a lot of development time on, and therefore no-one has actually looked and noticed that the only problem was that they should have left FINALDELAY completely alone. Your fix sounds pretty watertight, I don't see how it can affect anything else.

If you know how, why not write a patch file and send it to them?

 

[Bidule0hm]

I guess the the decision-makers have taken the position that UPS control is a very peripheral function they don't want to spend a lot of development time on, [...]

It's already on of the custom files in /conf/base so it's a 5 min fix... they took like 100x times longer to discuss the problem in the bug tracker than the time it takes to implement it...

If you know how, why not write a patch file and send it to them?

Ok, where I need to send it?

 

[rogerh]

I don't know what the official way is, but I'd open a new bug on the problem and attach the patch to the bug report. Just briefly describe what's wrong and tell them your patch fixes it. You can refer to this thread if they are unconvinced it's a good idea! Oh, and if you do it through the GUI untick the box for adding a debug file as it is obviously irrelevant.

 

[Bidule0hm]

Ok, I'll do that asap ;)