-
@dennypage said in NUT package:
In order to make this work again, a change to the pfSense package is required. I have created a PR that will address this. You can track the PR here.
Renato was super fast in pulling the PR in. Thanks Renato!!!
Don't forget that your ups must be named "ups" for remote access by the Synology to work.
-
@kevindd992002 said in NUT package:
Oh btw, do you have any thoughts on the random disconnection issues I'm experiencing? It looks like it is related to the USB drivers or something.
Usually this is associated with the bridge chip. Things that I would recommend to try:
- Use a high quality cable to the UPS
- Try a different USB port on the host (particularly USB3 vs USB2)
- If you have a hub involved, try removing it
- If you don't have a hub involved, try adding one (hub bridge chips are usually different than host bridge chips)
Also, have a look in the system log to see of there are any USB messages concerning the disconnect/reconnect.
-
Wow, that was real fast! When a PR gets merged to master, does pfsense automatically upgrade the package? And yes, I already renamed my UPS to "ups", thanks for the tip!
-
I'm using the supplied cable from APC and I believe it is high quality. I use an PCEngines APU2C4 board for my pfsense box which only has two built-in USB3 external ports and tried both of them already. No hub involved but yeah I can try.
Yeah, I might dig into the logs and correlate with the timestamp of the notification email.
FWIW, I have the same setup in another house (same UPS, pfsense box, and cable) and never received a communication error with that.
-
@kevindd992002 said in NUT package:
Wow, that was real fast! When a PR gets merged to master, does pfsense automatically upgrade the package? And yes, I already renamed my UPS to "ups", thanks for the tip!
It's not normally this fast. Renato is a great guy, trying to help us out.
Anyway, I expect that the updated package is available to you. It was already available in the factory package repo when I posted earlier.
You have to explicitly upgrade the package. See System / Package Manager / Installed Packages.
-
@kevindd992002 said in NUT package:
I'm using the supplied cable from APC and I believe it is high quality. I use an PCEngines APU2C4 board for my pfsense box which only has two built-in USB3 external ports and tried both of them already. No hub involved but yeah I can try.
Yeah, I might dig into the logs and correlate with the timestamp of the notification email.
FWIW, I have the same setup in another house (same UPS, pfsense box, and cable) and never received a communication error with that.
Definitely worth looking at the logs for anything about the comm error. FWIW, I've had generally good experience with the APU2, but haven't used a UPS with it. Of course, it's possible it's a flakey cable or UPS unit.
-
Yeah, I got it to work now :) As for WinNUT, do you have any epxerience with it? Is there a GUI version that I can use for my Windows machines?
-
Well, it could be also a conflict with apcupsd as I have it installed in this box as well. I just removed it and let's see if that solves the issue.
-
@dennypage said in NUT package:
@kevindd992002 said in NUT package:
-
I installed apcupsd and noticed some discrepancy with NUT. I'm not sure if this is a bug regarding the BATTDATE (apcupsd) and battery.date (NUT) but BATTDATE shows the correct date of 2016/05/11. While NUT shows the battery.date as 2001/09/25 which doesn't make sense. Any ideas?
-
Also, is the APCUPSD-UPS drive client of NUT the "remote apcupsd" connection method that @Grimson is referring to?
-
Is there a guide for NUT that I can read?
-
With NUT, can you set pfsense and other servers in the network to turn off when the battery charge hits 70%?
-
The pfSense NUT package reports what the NUT upsc command returns (without interpretation). Either the NUT driver that supports the UPS doesn't handle the string correctly, or apcupsd caches the battery change date in the local file system. I would consider the caching to be highly unlikely, but it's possible. Either way, the best place to enquire would be the NUT mailing lists. You can find information here.
-
Yes.
-
Yes, the NUT support site has a user guide and manuals.
-
Yes, local and remote shutdown is what NUT does for a living. Information on remote access in the second post of this thread. Plenty of discussion about controlling shutdown percentages earlier in this thread. Look for things like this:
ignorelb override.battery.charge.low = 50 override.battery.runtime.low = 60See the 'ignorelb' section in the ups.conf manual for details on this.
I take it that you just enter these arguments in the "extra driver arguments" section and you're all set. Are these globally applicable though, meaning the same override settings will apply for the master and slaves?
Also, do I need to set both or just the percentage? What's a good value if I aim to "preserve" battery life? Or is it generally recommended to run the UPS (when mains are cut) until the battery is depleted so that you actually take advantage of the the full capacity of the battery?
-
-
Yes, the slaves follow the master. The master sends the slaves a shutdown order, and then waits for them all to disconnect. Once the slaves have disconnected, the master shuts down.
Yes, the battery overrides go in the Extra Arguments to driver section. One or both is up to you. If you are running a Synology as a slave, I would certainly set the runtime.low a bit higher to ensure that the Synology has sufficient time to shutdown. I believe I'm using 300 on mine.
As to charge.low, that's personal preference. The more times you discharge a lead acid battery the shorter its life, but that's why you have a UPS in the first place isn't it? The trade off between surviving an outage and battery health is a personal choice. Note that even if you baby the battery, you're still going to have to replace it every few years.
-
That's what I thought.
So if I set both overrides, the master will send a shutdown order whichever between the two thresholds it hits first, correct? And I believe you also have to set the "warning" override to be higher than the "low" override?
Yes, that's what I thought but it's just that in our place, whenever a blackout occurs, it's a long one. So keeping it in battery mode until depleted is not achieving anything. When a blackout occurs, no one will ever stream off of the NAS anyway because all streaming devices are forcefully turned off by the blackout :) So might as well conserve battery charge (hence savings a bit of its life more), if you know what I mean. So yeah, I guess it really just depends on the use case.
-
@kevindd992002 said in NUT package:
@dennypage
So if I set both overrides, the master will send a shutdown order whichever between the two thresholds it hits first, correct? And I believe you also have to set the "warning" override to be higher than the "low" override?Whichever comes first is correct. Warning is essentially just a syslog entry.
-
Gotcha. Is the battery.runtime.low threshold the time left in the battery's charge or the total time the UPS is running without connection to the mains?
-
They are both "low" conditions. The NUT documentation describes this.
-
Ok. I'm testing NUT now with only pfsense running as the master and no slaves. I'm noticing a very strange behavior that totally doesn't make sense to me. So here's what I did (in chronological order):
- Set override.battery.charge.warning to 55 and override.battery.charge.low to 50.
- I started with a full charge battery and unplugged the UPS from the mains.
- The UPS status in the pfsense picked up the change and says Online, discharging.
- As soon as the battery charge hits 50, the state changed to FSD which is what is expected. So far so good.
- Since no slaves are present, the pfsense box turned off itself pretty quick.
- The UPS waited for a few more seconds before it finally cut off the load power to the rest of its ports. All good.
- Now I plug the mains back into the UPS. As soon as I do this, the UPS turns on BUT stays at battery mode (so discharging).
- It supplies power back to all ports and pfsense and the other devices started booting.
- Then the UPS itself detects that the battery charge is still below 50% (of course, because it needs time to charge and it is even at a discharging state now) and then a few seconds later the unit turns off again. It seems that the killpower command given to it by the pfsense is still being enforced even though the mains is already connected and providing power.
- Then it turns on by itself again. And this vicious cycle continues over and over until I disconnected the USB serial connection in the back of the UPS.
What have I done wrong here? Why doesn't the UPS detect that the mains power is already back when the USB serial connection is plugged in. It seems to me that the command given by the pfsense NUT package is messing the behavior of the UPS.
-
The pfSense NUT package doesn't send commands to the UPS. The package generates the NUT configuration, the result of which you can find in /usr/local/etc/nut. All communication with the UPS is handled by NUT.
If the UPS is staying on battery after the mains are restored, either the UPS is defective or it needs a startup delay configured. The NUT documentation has information on startup delays.
-
I don't think the UPS is defective because when I directly connect the USB cable to a Windows machine with PowerChute installed, everything works just fine when I do the same test.
Why would it need a startup delay?
-
Because it configures the amount to recharge the UPS to before turning back on. You can simulate by leave load off whilst the batteries charge back to 90% and when you power up you’ll see it operate correctly.
Read up on the startup delay Denny mentioned. It’s probably your answer. -
You said “... I plug the mains back into the UPS. As soon as I do this, the UPS turns on BUT stays at battery mode (so discharging). It supplies power back to all ports ...”
If the UPS stays on battery even though mains have been restored, then that is a defect. It may be “by design” but it is still a defect. The UPS should return to main power before reenergizing the ports.
Sometimes you can work around defect by design issues like this by setting delay parameters in the UPS, which is why I suggested that you read up on the various delay values. Ups.delay.start in particular.
-
Exactly. But like I said, this only happens when the USB cable is plugged unto NUT. So there's somrthing going on with the UPS when NUT issues a killpower order. I would've noticed this issue long ago (when I wasn't still using NUT) if it also occured when using PowerChute, or if it happens when the USB serial cable is unplugged. Does that make sense?
Yes, I will read up on that delay parameter later.
