-
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.
-
@q54e3w said in NUT package:
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.In the NUT user manual (variables section), it says this:
ups.delay.start - Interval to wait before restarting the load (seconds)
This is in seconds. How does that description relate to what you said (it configures the amount to recharge the UPS to before turning back on)? Sorry, I'm confused and I can't find any start delay variable description that is close to what you're describing.
-
Run your 10 count test again. After step 6, unplug the serial cable. How long does it take after step 7 does it take for the ups to come off battery and return to the mains? That is The startup delay you are trying to achieve.
-
If it only happens when the USB cable is connected then its possible your master is detecting the low battery condition still exists and instigating the shutdown again, this is potentially a poor driver or faulty hardware. Which brand & model is this?
The UPS should be should report its on mains power which should prevent this. With my APC and Eaton units (both with network cards) I rcall shutdown only triggered when (on battery AND battery charge < X%). -
@dennypage said in NUT package:
Run your 10 count test again. After step 6, unplug the serial cable. How long does it take after step 7 does it take for the ups to come off battery and return to the mains? That is The startup delay you are trying to achieve.
@q54e3w said in NUT package:
If it only happens when the USB cable is connected then its possible your master is detecting the low battery condition still exists and instigating the shutdown again, this is potentially a poor driver or faulty hardware. Which brand & model is this?
The UPS should be should report its on mains power which should prevent this. With my APC and Eaton units (both with network cards) I rcall shutdown only triggered when (on battery AND battery charge < X%).I think I know what I did wrong. In step 7, I plugged the mains too early causing a power race condition as described by point #51 here . I thought that when APC BR1500GI's display went black (even with the fans still running) it is already in a shutdown state. This was not the case, it waited for a few more seconds until it totally went silent. At that time, I plugged the mains back and everything was working as expected :)
A question regarding the workaround implementation on point #51 of that FAQ article though. Where, in the pfsense NUT package, do I implement that if statement?
-
Unless you have a “stupid” ups, no. You may want to read up on offdelay and ondelay. But likely there is nothing else you need do. Just be happy.
-
What do you mean no?
Well, there's still a chance (though slim) that a power race condition will happen. So might as well implement thst if statement as a workaround, no?
-
-
I'm confused. I was able to recreate the power race problem. Are you saying that this happens with a very low probability that makes it not worth applying the workaround? Sorry, I know I'm persistent but I'm just into the nitty-gritty details.
EDIT:
Also, do you have any ideas about this? https://forum.netgate.com/topic/109510/upsmon-parent-process-died-shutdown-impossible/5 . I'm encountering the same issue every now and then.
-
Would you be able to continue helping me? Thanks.
-
I’m traveling, so it’s a bit hard atm. Not sure what additional help you need. Not sure what you tested was the issue referred to in the link. Regardless, offdelay and ondelay are likely what you need to look at.
-
Sorry.
So basically, I wanted to solve the power race problem wherein the UPS acts weird when the mains comes back exactly during its shutting down phase. There's already a script written in NUT's FAQ page but you mentioned that I don't need to do that and insteast just concentrate on ondelay and offdelay. I'm confused why I don't need to solve the power race problem according to what you said. What's the difference between implementing that script and implemnting off/ondelay?
As for the link I posted, that's regarding the upsmon parent process died error message that's being sent through email notification. I haven't gotten it in a few days now but was wondering what you thought about that since you replied to that old thread at one point.
-
The workaround you reference indicates that it is for dealing with contact closure (dumb) UPS units. But you don’t have one of those.
It’s unclear to me what you have experienced. The nut users list is a better place to seek help with core nut behavior.
-
I have a TrippLite ECO 850 LCD. The UPS is about 4-6 months old, has a 100% capacity still, and has been working flawlessly. It's ECO mode is tured off.
I gracefully rebooted my pfSense three days ago. Since then, I've been receiving the following notices every 10 minutes. I get the first one and then about 5 seconds later I get the second one. Then 10 minutes later I get the same two messages again. When this started, I checked and there was an update for NUT that I installed. This didn't help. I've rebooted pfSense again and that didn't help.
Is there additional information I can supply or steps I can try to resolve this issue?
Subject: UPS Notification from pfsense.domain Mon, 10 Sep 2018 08:28:51 Communications with UPS TrippLite_ECO850LCD lostSubject: UPS Notification from pfsense.domain Mon, 10 Sep 2018 08:28:56 Communications with UPS TrippLite_ECO850LCD estabished -
@pfserik
Most often this is cause by flakey USB connectivity. You kind of have to use the cable that came with the unit, so unless you have another unit to swap cables with it's kind hard to check that. If you have multiple USB hubs in the box, try one of the ports connected to a different hub. Lastly, if you you can try add/remove of an external hub.It could also be a bad UPS, but I think that unlikely. When these unit fail, it is usually complete. Worth running a self test however. Note of caution: although undocumented, when you run a self test the ECO sockets get turned off even if you have ECO disabled. I found that out the hard way.
Btw, I assume you are running 2.4.3-RELEASE-p1, yes?
