-
I have attached screenshots of my UPS status and settings page. Yep, seeing the values on the UPS Status page.
The warning that the UPS requires attention appears to be correct. Note that the status is "On line, Bypass"? Bypass is bad. Bypass means that the UPS inverter has been bypassed and will not take over if the mains fail. If you scroll down to the bottom of the UPS Detail section, you should see a field titled "ups.alarm" which will hopefully give you a better indication of why bypass is active.
I'm surprised that there wouldn't be an alarm going off on the thing.
-
I have attached screenshots of my UPS status and settings page. Yep, seeing the values on the UPS Status page.
The warning that the UPS requires attention appears to be correct. Note that the status is "On line, Bypass"? Bypass is bad. Bypass means that the UPS inverter has been bypassed and will not take over if the mains fail. If you scroll down to the bottom of the UPS Detail section, you should see a field titled "ups.alarm" which will hopefully give you a better indication of why bypass is active.
I'm surprised that there wouldn't be an alarm going off on the thing.
For all intents and purposes, the UPS is functioning correctly (aside from the bypass status reading). I am using a generic UPS driver for NUT (it was a trial and error process at the time to find a driver that worked as there was none from the UPS manufacturer), perhaps that is the cause for the "incorrect" bypass reading (I say incorrect because if I disconnect the mains the UPS functions correctly). Anyway, it's not a major problem for me as it is just aesthetics for now.
-
Okay, glad it's working.
Was nutdrv_qx one of the drivers you tried?
-
Okay, glad it's working.
Was nutdrv_qx one of the drivers you tried?
I don't recall specifically at the time if I tried the driver. However, I tried it today and it does not work. Currently the blazer_ser driver is working (the best) for my setup.
-
Thanks alanper, appreciate you letting me know.
-
Hi
I have recently upgraded to 2.3 - specifically 2.3.2-RELEASE-p1 (i386) - on my Alix device. In the process NUT was upgraded to 2.7.4_3. On visiting the NUT service page I was asked to confirm the upgrade settings. The UPS Type (local serial) and Driver (apcsmart) had been preserved so I didn't think further and hit 'save'. NUT didn't work despite restart. I believe I know why as I have successfully worked around…
By hitting 'save' I overwrote the correct serial port setting with one of the ones presented by the drop-down on the serial port field. The issue seems to be this... the serial port only allowed me to choose from the two built in UARTS on the board /dev/cuau[0-1]. I have a USB-to-serial adapter and this assigns a character device called /dev/cuaU0 (note U/C 'U'). Once I had SSH'd into the box and spotted the issue, editing the conf file and restarting NUT cause everything to spring back into life.
I should also say that I am new to this sort of meddling with conf files. I think these are not really the masters as far as configuration is concerned, i.e. they are auto-generated from elsewhere. i can see, for example that my entries in the other ups*.conf files are not reflected in the NUT UI. Should I be doing this a different way?
BTW, thanks for all the efforts porting this service, I hope this feedback proves useful.
Regards
- Steve
-
Sorry about the problem Steve. Best that I can tell, in FreeBSD 10.3 and above call-out serial ports are all supposed to match the pattern "/dev/cuau?" which the device you have doesn't. Is the driver for this adapter included in the FreeBSD distribution or is it something that you had to install separately from the vendor? Can you tell me the name of the driver?
I don't have an issue adding support for uppercase 'U', but I would like to make I understand what's going on first. Thanks.
The issue seems to be this… the serial port only allowed me to choose from the two built in UARTS on the board /dev/cuau[0-1]. I have a USB-to-serial adapter and this assigns a character device called /dev/cuaU0 (note U/C 'U').
-
Hi,
The driver is called "uchcom.ko".
Cheers
- Steve
-
Dennypage,
I've seen an issue going on where the NUT service gets reset if the WAN connection is lost causing UPS communication loss. My current setup has my ATT modem in a different area not on UPS backup, so when the power flickers the modem resets. This is not a permanent setup, eventually the modem will be relocated inside the main rack which it will then be powered by the same UPS as the pfsense box.
However, if my WAN link goes down, why should the NUT service be affected? If an extended power outage was to happen currently keeping my WAN link down, the pfsense box would never shutdown because its now lost communication with the UPS.
-
Hey Bulldog. pfSense restarts services when the WAN interface disconnects/reconnects. Yes, this is unnecessary for some services such as NUT, but there is no way for pfSense to know which services actually need to be restarted.
What you would expect to see is NUT restart once when the interface goes down, and once again when the interface comes back up. Is this what you are seeing? Or are you seeing the NUT service stopped the entire time the interface is down?
-
Hey Bulldog. pfSense restarts services when the WAN interface disconnects/reconnects. Yes, this is unnecessary for some services such as NUT, but there is no way for pfSense to know which services actually need to be restarted.
What you would expect to see is NUT restart once when the interface goes down, and once again when the interface comes back up. Is this what you are seeing? Or are you seeing the NUT service stopped the entire time the interface is down?
I will need to verify if it stays dead the entire time.
-
Steve, I've pushed a fix for this. The release number will be 2.7.4_4. It may take a few days to work it's way through the system.
Thank you for your help in sorting this out. Much appreciated.
The issue seems to be this… the serial port only allowed me to choose from the two built in UARTS on the board /dev/cuau[0-1]. I have a USB-to-serial adapter and this assigns a character device called /dev/cuaU0 (note U/C 'U').
-
Or, it could come out the same day it's pushed. :)
Steve, when you have a minute, can you confirm that this fixed the issue for you please?
Thanks.
Steve, I've pushed a fix for this. The release number will be 2.7.4_4. It may take a few days to work it's way through the system.
-
hello,
I have an "NoName Polish brand" ups connected on Local USB that work with blazer driver in 2.3.2-RELEASE-p1 (amd64).
I get few emails every day with "UPS is unavailable" and "Communication with UPS lost" even I set cron to restart NUT every 9 minute.
Is it possible to edit and add NUT restart command to UPS monitoring module instead of sending this emails ?
Any idea where to look ?Usually a manual restart of UPS monitoring daemon it fix the problem before cron but it is getting annoying to receive so many emails and entries in syslog from NUT… :o
thank you
edit:
I try now to automate restart ups service with:
upssched.conf
CMDSCRIPT /usr/local/bin/custom-upssched-cmd PIPEFN /var/db/nut/upssched.pipe LOCKFN /var/db/nut/upssched.lock AT NOCOMM * START-TIMER ups-no-comm 20 AT COMMBAD * START-TIMER ups-comm-bad 20 AT COMMOK * CANCEL-TIMER ups-comm-bad COMMOKcustom-upssched-cmd
#!/bin/sh NAME=`basename $0` LOGGER="/usr/bin/logger -t $NAME" case $1 in ups-no-comm|ups-comm-bad) $LOGGER "Timer event '$1' fired, restarting NUT..." /usr/local/etc/rc.d/nut.sh restart ;; *) $LOGGER "Unrecognized command: '$1'" ;; esac -
Continual disconnects generally indicate an issue with the driver, USB hardware, or with the UPS itself. Before trying to implement scripting work-arounds, I would recommend confirming the source of the problem. Lots of suggestions for this…
First thing I would check would be the physicals: good USB cable, direct connection with no hub, etc. Also, try a different USB port and see if this affects the behavior. Run "usbconfig dump_device_desc" during normal operation. What is the vendor id? Does it match what you expect? Run usbconfig again after the disconnect happens. Does the device still appear?
I would also validate the NUT driver. Did the vendor recommend using the blazer driver? Have you tried any of the other usb based drivers? On the Services / UPS /Status page, do all the items in the UPS Detail section make sense? Are they reasonable values? If not, then there is a driver/configuration problem.
-
After ~12h since my last post when I deleted the cron restart job every 9 minute and I added upssched.conf and custom-upssched-cmd until now I have 0 lost/bad communication event.
here are some data from USB and UPS with my settings
ugen0.2: <usb to="" serial="" inno="" tech=""> at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0000 <probed by="" interface="" class=""> bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0008 idVendor = 0x0665 idProduct = 0x5161 bcdDevice = 0x0002 iManufacturer = 0x0001 <inno tech=""> iProduct = 0x0002 <usb to="" serial=""> iSerialNumber = 0x0000 <no string=""> bNumConfigurations = 0x0001</no></usb></inno></probed></usb>upsmon.conf
DEADTIME 21 POLLFREQ 7 POLLFREQALERT 7 SHUTDOWNCMD "/sbin/halt -p"ups.conf
pollinterval = 7 default.battery.voltage.high = 13.7 default.battery.voltage.low = 11.5 runtimecal = 180,100,360,50 ignorelb override.battery.charge.low = 50 override.battery.runtime.low = 600UPS Detail Variable Value battery.charge 100 battery.voltage 13.70 battery.voltage.high 13.00 battery.voltage.low 10.40 battery.voltage.nominal 12.0 device.type ups driver.name blazer_usb driver.parameter.pollinterval 7 driver.parameter.port auto driver.parameter.synchronous no driver.version 2.7.4 driver.version.internal 0.12 input.current.nominal 2.0 input.frequency 50.0 input.frequency.nominal 50 input.voltage 241.2 input.voltage.fault 241.2 input.voltage.nominal 230 output.voltage 241.2 ups.beeper.status enabled ups.delay.shutdown 30 ups.delay.start 180 ups.load 19 ups.productid 5161 ups.status OL ups.type offline / line interactive ups.vendorid 0665Blazer is the only driver that work with this UPS, about the vendor of this ActiveJet UPS they have 0 support and documentation and don't replay at emails, I bought this one because it has UTP port IN/OUT isolation which I am using for WAN but I found that is not documented or marked which one is IN and which is OUT…
-
USB to serial adapters are often the source of problems.
You might try adding this global directive:
pollinterval=10
to the section entitled "Additional configuration lines for ups.conf" in Services / UPS / Settings / Advanced Settings.
-
Now after I deleted cron UPS schedule restart I don't have any more problems with lost communication, zero problems in 2 days !
Using upssched.conf & custom-upssched-cmd is the proper way to deal with lost communication if you ask me, no need to schedule a restart for UPS driver if communications is good.
edit:
I was to happy… worked only 2-3 days...
-
Something is NOT OK !
After 2-3 days without any problem today without any reason UPS communication went offline and no chance to be restored with the changes I made to
custom-upssched-cmd & upssched.confI think commands I defined there are not executed, syslog show no trace of NUT service restart.
I restarted manually the service but this problem continued… randomly.
even I changed:DEADTIME 30
POLLFREQ 10
POLLFREQALERT 10
and
pollinterval = 10No chance to fix for long term... communication go offline randomly.
Only pfsense reboot solved the UPS communication problem.
Definitely a NUT problem as I did not touched anything on UPS.
Any ideas ?
Do I need something else to set for upssched to work ??I hope I don't have to return to cron schedule NUT restart… because to schedule a pfsense reboot every night for NUT to work properly it is not a good option.
-
Dude, how about changing your "NoName Polish brand" UPS for something that works, instead of wasting time and blaming NUT?
