NUT
-
I am trying to get nut working on my Soekris net-5510-70 board. I am running 1.23 full on a HD and when I run the start command for nut, this is what I get.
/usr/local/etc/rc.d/nut.sh start
starting usbhid-ups
Network UPS Tools - UPS driver controller 2.2.2
Network UPS Tools: 0.29 USB communication driver - core 0.33 (2.2.2)No matching HID UPS found
Driver failed to start (exit status=1)
usbhid-ups failed to startWhen I unplug the USB, this is what shows up in shell
unknown: at uhub0 port 1 (addr 2) disconnected
unknown: at uhub0 port 1 (addr 2) disconnected
Is there a way I can add my APC XS 1000 to work with this?
-
When it's plugged in, what does the output of "usbdevs" show? And is that really how the log entries look in the system log? Usually it doesn't say unknown, it would say something like "ugen0".
-
Yeah that's what it shows in the logs.
-
Hello,
Same issue on ALIX 2C3 / pfSense 1.2.3 with a Eaton Ellipse ASR 600 USBS (ex. MGE APC) connected through the USB cable :
dmesg
unknown: at uhub0 port 2 (addr 2) disconnected
usbdevs -v
Controller /dev/usb0:
addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AMD(0x0000), rev 1.00
port 1 powered
port 2 addr 2: low speed, power 20 mA, config 1, ELLIPSE(0xffff), EATON(0x0463), rev 0.01
port 3 powered
port 4 powered
Controller /dev/usb1:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), AMD(0x0000), rev 1.00
port 1 powered
port 2 powered
port 3 powered
port 4 poweredcat ups.conf
[mgeups]
driver = usbhid-ups
port = /dev/usb0
desc = "Office Ellipse ASR600 UPS"/usr/local/etc/rc.d/nut start
Network UPS Tools - UPS driver controller 2.4.1
Network UPS Tools - Generic HID driver 0.34 (2.4.1)
USB communication driver 0.31
No matching HID UPS found
Driver failed to start (exit status=1)/usr/local/libexec/nut/usbhid-ups -a mgeups
Network UPS Tools - Generic HID driver 0.34 (2.4.1)
USB communication driver 0.31
No matching HID UPS found -
Just to be clear, have these ever worked? Or did they used to work and now stopped?
Because if FreeBSD doesn't pick up on a driver for the UPS when it's plugged in, NUT may not see it either.
-
On my side, this is the first attempt…
I may try through the serial cable.
-
Then that UPS may not be supported on FreeBSD.
Is it in the list of available choices in NUT?
Or did you just choose a closer or generic model?
-
This one :
cat driver.list | grep "Ellipse ASR USBS 600"
"Eaton" "Ellipse ASR USBS 600/750/1000/1500 VA" "USB cable" "usbhid-ups"
"Eaton" "Ellipse ASR USBS 600/750/1000/1500 VA" "Serial cable" "mge-shut or newmge-shut"
"MGE Office Protection Systems" "Ellipse ASR USBS 600/750/1000/1500 VA" "USB cable" "usbhid-ups"
"MGE Office Protection Systems" "Ellipse ASR USBS 600/750/1000/1500 VA" "Serial cable" "mge-shut or newmge-shut" -
It would have to be a driver issue for you at that point then, if it's plugged in but the NUT driver doesn't see it.
I haven't checked in a couple weeks but as of a month ago or so we are on the most current version of NUT.
You could try a 2.0 snapshot to see if it behaves any differently.
-
Not better through the serial cable :
cat ups.conf
[mge-ups]
driver=mge-shut
port=/dev/ttyd0/usr/local/etc/rc.d/nut.sh start
starting mge-shut
Network UPS Tools - UPS driver controller 2.4.1
Network UPS Tools - MGE UPS SYSTEMS/SHUT driver 0.68 (2.4.1)
No communication with UPS
Driver failed to start (exit status=1)
mge-shut failed to start/usr/local/libexec/nut/mge-shut -a mge-ups
Network UPS Tools - MGE UPS SYSTEMS/SHUT driver 0.68 (2.4.1)
No communication with UPScat ups.conf
[mge-ups]
driver=newmge-shut
port=/dev/ttyd0/usr/local/etc/rc.d/nut start
Network UPS Tools - UPS driver controller 2.4.1
Network UPS Tools - Generic HID driver 0.34 (2.4.1)
MGE SHUT communication driver 0.81
Warning: This is an experimental driver.
Some features may not function correctly.No matching HID UPS found
Driver failed to start (exit status=1) -
Port should be /dev/cuad0 and not a ttyd device
-
Thanks for your help !
Now : port locked
/usr/local/etc/rc.d/nut start
Network UPS Tools - UPS driver controller 2.4.1
Network UPS Tools - MGE UPS SYSTEMS/SHUT driver 0.68 (2.4.1)Unable to open /dev/cuad0: Device busy
Current user id: uucp (66)
Serial port owner: uucp (66)
Serial port group: dialer (68)
Mode of port: 0660Things to try:
-
Use another port (with the right permissions)
-
Fix the port owner/group or permissions on this port
-
Run this driver as another user (upsdrvctl -u or 'user=…' in ups.conf).
See upsdrvctl(8) and ups.conf(5).
Fatal error: unusable configuration
Driver failed to start (exit status=1)ll /dev/cuad*
crw-rw---- 1 uucp dialer 0, 41 Jan 1 2000 /dev/cuad0
crw-rw---- 1 uucp dialer 0, 42 Jan 1 2000 /dev/cuad0.init
crw-rw---- 1 uucp dialer 0, 43 Jan 1 2000 /dev/cuad0.lock
crw-rw---- 1 uucp dialer 0, 47 Jan 1 2000 /dev/cuad1
crw-rw---- 1 uucp dialer 0, 48 Jan 1 2000 /dev/cuad1.init
crw-rw---- 1 uucp dialer 0, 49 Jan 1 2000 /dev/cuad1.lock -
-
Oh yeah, you were on an ALIX. Its serial port is already in use for the console output and can't be used for anything else.
Though if you had a second serial port, that would be cuad1, at least on 1.2.x… on 2.0 they're cuau0/1, and USB to serial adapters are cuaU0/1/etc. Look for any /dev/cua*
-
Hello,
As you can see above, I indeed have a cuad1 device, but again :
cat ups.conf
[mge-ups]
driver=mge-shut
port=/dev/cuad1/usr/local/etc/rc.d/nut start
Network UPS Tools - UPS driver controller 2.4.1
Network UPS Tools - MGE UPS SYSTEMS/SHUT driver 0.68 (2.4.1)
No communication with UPS
Driver failed to start (exit status=1)Are the device rights correct ?
-
I have the same problem with a Cyberpower Systems Value 600E using the USB interface. The problem is in the FreeBSD kernel. Either the FreeBSD core needs to be patched, the pfSense distro needs to be patched or we as individuals make our own custom pfSense kernels for our own use.
http://www.mail-archive.com/nut-upsuser@lists.alioth.debian.org/msg04580.html
-
Try 2.0 first then to see if it works there. pfSense 2.0 is based off of FreeBSD 8.1, and has a different set of patches. Not sure if we include that one, but it's possible.
If it works on 2.0, it's likely an OS issue and can't/won't be fixed on 1.2.x (unless you want to go through the trouble of making your own custom kernel…)
