Re: [Nut-upsuser] Sven Power Pro 1000+
Citeren Vlad n...@wolf.umail.net: I'll try to install dev version and see whether it works. What kind of diagnostic info would you need? USB ID of my device is :. Could you also try the blazer_usb driver from nut-2.4.3 (the same version as the megatec_usb driver that worked for you)? /path/to/blazer_usb -DDD -u root -a upsname Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] tcgetattr: Inappropriate ioctl for device
Citeren Martin Ivanov tra...@abv.bg: root@alhana:/etc/nut# /etc/rc.d/rc.ups start Network UPS Tools - UPS driver controller 2.6.0 Network UPS Tools - Generic contact-closure UPS driver 1.36 (2.6.0) UPS type: Repoteck RPT-800A, RPT-162A tcgetattr: Inappropriate ioctl for device Driver failed to start (exit status=1) Does this mean that the driver is not supported or am I missing something? The genericups driver is for serial devices only. Only if the UPS has a supported USB to serial converter on board that is recognized by the kernel, you can use it. But in that case, you'd need to configure the /dev/ttyUSBx port that is created, not the USB port. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Sven Power Pro 1000+
Citeren Martin Ewing martin.s.ew...@gmail.com: This seems very similar to the trouble I have with a Belkin UPS (USB) with Natty (64 bit). Not at all. You seem to be suffering from a permissions problem, where Vlad is not (most likely, there is a problem in the protocol handling). These are totally unrelated issues. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Sven Power Pro 1000+
Citeren Vlad n...@wolf.umail.net: I downgraded back to 2.4.3, configured nut to use megatec_usb again, and it started working again. However, it seems strange that I cannot use the latest version. This is not strange at all. We have reworked this driver core and could not find people with access to these device and willing to test this. Note that blazer_usb has been in the stable version since 2.4.0 was released and have urged people to switch over to this one. We have had no reports that the subdriver that is used by this series of UPS devices was broken. In that case, there is nothing more we can do than to switch to the new driver and see what happens. We've had some changes after 2.6.0 was released in this driver, so you could try if upgrading to that helps. There are some more changes underway, but due to the lack of help we're getting from the userbase, this is put on the back burner (without people volunteering to test changes, there is no point in putting effort in it). You could help us here by running the development version for this driver and report back your results, since we will need testing from as many different flavors of the krauler series of devices as possible (USB ID's 0001: and :). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Nut-upsuser Digest, Vol 72, Issue 21
Citeren Raphaël raphael.brou...@ve-hotech.com: Testing PID before launching a new instance of driver is a good solution but need to be implemented in /etc/init.d/nut So, what's the big deal here? This is just a script on most (if not all systems) that can be modified easily. On the other had, changing the binaries is usually much more difficult. The sleep solution is incorrect because if i do in parallel twice (stop,sleep,start). The two starts will be done at the same time ( i mean stop will be already done) and there will be 2 instance of driver. Are you using 'upsdrvctl'? I fail to see the problem mentioned above, because 'upsdrvctl' will not start two drivers with identical names, so the problem can't occur (unless you're running 'upsdrvctl start' twice in a row). Or i dont understand. Or I don't. Could you post your 'ups.conf' here? Are you trying to monitor two identical UPS devices? Testing PID before and launching new instance of driver if pid does not exist) sould be the right solution but only if 2 UPS needs 1 driver else this solution fails No, the name of the driver and UPS are in the PID filename, so we can easily check if that exists (in fact, the development version will do that). But this doesn't completely solve the problem, since this is prone to race conditions. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Restarting NUT twice in the same time creates 2 instances of usbhid-ups driver
Citeren Raphaël raphael.brou...@ve-hotech.com: When reading /etc/init.d/nut, i see that when restarting nut, script stop nut and start it again. When starting again the driver is one more time started without any verification that its already launched. Stopping a driver is an asynchronous process. So you either have to check if the PID file is removed before assuming the driver has actually stopped or you need to wait a couple of seconds before (re)starting the drivers. I think there is a problem in code there. This is an inherent effect of the method that is used to signal drivers to stop. On systems with multiple driver instances, you don't want to hang around waiting for a driver to actually stop before going to the next one. have you a solution to bypass this problem without rewriting /etc/init.d/nut The easiest fix is to add a delay between stop nut sleep 2 start nut Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Using NUT to detect a normally closed circuit opening
Citeren James Smith james.sm...@jofco.com: I now have everything in place and I get an email when the temp sensor opens Question - what do I set so the system doesn't shut down when the sensor stays open? The system will only shutdown if you have an OB+LB event at the same time. As long as you make sure the system sees either OB or LB, but not both, you'll be fine. Can I just set SHUTDOWNCMD ? This isn't needed. Note that there is a fatal flaw in a setup where opening a contact triggers an event. You'll have no way to verify that there is not a short in your cable, short of raising the temperature periodically to see if you see something changing. I wouldn't recommend using a temperature switch for anything else than a redundant over temperature kill switch, especially since USB connected temperature sensors are very cheap nowadays. This would allow you to monitor the health of your alarm system much easier. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Using NUT to detect a normally closed circuit opening
Citeren James Smith james.sm...@jofco.com: So how do I make sure it never sees the LB event (or ignores it)? By wiring you sensor so that it either sets OB or LB and hard wiring the other to the inactive state. [...] The point about the short is a valid one, but I don't think it will be an issue (if it ever does become an issue, I can change the sensor out for a normally open one and change the driver file accordingly) This fails in a similar way - you have no way to determine if the sensor is not connected or if it is in the below limit temperature range. For an alarm system to be reasonably robust, you need to continuously monitor the health of your sensor and interconnect as well. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] RPT-1003AU driver?
Citeren Martin Ivanov tra...@abv.bg: Browsing the compatibility list of nut has revealed that there are NUT drivers for the RPT-162A (genericups upstype=13) and RPT-800A and RPF525/625/800/1000 modes (safenet). Is it possible that any of these drivers work, and if yes, which one? As far as I can tell, we have never seen reports about this particular model. The only way to check the compatibility is to try it out. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Re : Richcomm Serial driver
Citeren Manzoor e Elahi manzoor.e.el...@gmail.com: Here's something more I've found using the new soft. Please take a look. If you have such a table available, you can figure out quite easily which upstype is applicable here: cable power = DTR online = CTS off low battery = CD on This looks like a 'genericups upstype=3' or 'genericups upstype=20' device. The only thing left to check is which shutdown command works (most likely, the UPS has to be on battery for that to work). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] nut problem on boot/restart
Citeren Jose Álvarez dynami...@hotmail.com: When I turn on my pc everything works fine, but if I restart fails (I'm not sure if this is true at 100%) (then, i can do 'sudo /etc/init.d/nut restart' and it works) This usually means that you're attempting to use the USB bus before it has initialized. But what is certain is that sometimes when start up the pc it works and sometimes fails, can be a problem with the start time (i have a fast ssd) and the initialization of the driver and the usb port? The latter. [...] Don't inline log files. The formatting will usually not be preserved and they become very hard to read. Please attach log messages (and preferably, gzip them too to save bandwidth and prevent the mailinglist from rejecting them because of size). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problem with blazer_ser/megatec when upgrading to 2.6.0 from 2.4
Citeren Dushan Tcholich dus...@gmail.com: [...] /lib64/nut/blazer_ser -D -a munja -i 10 Network UPS Tools - Megatec/Q1 protocol serial driver 1.51 (2.6.0) 0.00 send_to_all: SETINFO driver.parameter.port /dev/ttyS0 Looks fine. [...] upsmon -D Network UPS Tools upsmon 2.6.0 0.00 UPS: munja@localhost (slave) (power value 1) 0.000153 Using power down flag file /etc/killpower 0.000261 debug level is '5' 0.001301 Trying to connect to UPS [munja@localhost] 0.002166 Logged into UPS munja@localhost 0.002184 pollups: munja@localhost 0.002197 get_var: munja@localhost / status 0.002279 Poll UPS [munja@localhost] failed - Driver not connected 0.002290 do_notify: ntype 0x0005 (COMMBAD) 0.002297 Communications with UPS munja@localhost lost 5.002588 pollups: munja@localhost 5.002617 get_var: munja@localhost / status 5.002758 Poll UPS [munja@localhost] failed - Driver not connected 5.002771 do_notify: ntype 0x0008 (NOCOMM) 5.002781 UPS munja@localhost is unavailable 10.003015 pollups: munja@localhost 10.003048 get_var: munja@localhost / status 10.003191 Poll UPS [munja@localhost] failed - Driver not connected 15.003280 pollups: munja@localhost 15.003309 get_var: munja@localhost / status 15.003450 Poll UPS [munja@localhost] failed - Driver not connected What am I missing? What is the output of 'upsd' in the syslog telling you? Note that when running in debug mode, a process will terminate as soon as you close the terminal it is running in or when you kill it with Ctrl-C. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Infinite loop with bcmxcp_usb and Powerware 5115
Citeren Rupert Hair rupert.h...@gmail.com: I'm running Solaris 11 Express (snv_151a X86) with NUT 2.6.0 compliled from the source tarball and a Powerware 5115. I was seeing the driver hang, What makes you think the driver 'hangs'? so gave it some '-D's (23 apparently ;-) and found that it seems to be getting into an infinite loop when reading data from the UPS. The driver doesn't background when you run it in debug mode. So what you're seeing, is what we expect. The debug output is attached and I would be very grateful for some help or advice on what to try next. Without more information on why you think the driver is misbehaving, debug output is useless (and you posted too little to be useful anyway). Please read what is said in the documentation about running drivers in debug mode before wasting our time here. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Richcomm Serial driver
Citeren Manzoor e Elahi manzoor.e.el...@gmail.com: Thanks for your replay. Actually my UPS uses a lite version of that software and only reports mains on/off, ups on/off and ups connected/disconnected status. I also think the genericups driver should work and tried all the driver types without any luck. Unfortunately I can't afford to ditch the UPS right now. I'll try the serial sniffing technique or use a multimeter to find out what's happening through the serial port. I've some experience with those. Can you give me some idea what I should be looking for? In case of contact closure devices, the easiest way to find this out is by using a RS-232 breakout box. You would find these in the toolbox of any engineer dealing with TTY consoles on mainframes a few decades ago. See for an example http://en.wikipedia.org/wiki/Breakout_box I actually have the model that is depicted on this page. This will indicate the status of the modem control lines by means of colored LEDs, making it very easy to see what happens. You could probably also do this with Portmon for Windows, by this requires more effort on your side. See http://msdn.microsoft.com/en-us/library/bb896644.aspx If you can lay your hands on a RS-232 breakout box, the few bucks you might need to pay for it are well worth it. One more question. Is it possible to use a USB to serial cable for a serial UPS with generic UPS driver? This combination works in Windows with the official software but what about NUT? Is any special configuration required for this? This depends on whether or not your kernel supports this device. If it is supported, usually a /dev/ttyUSBn (n = 0..15) port will be created by the kernel. You then connect the genericups driver to this as if it was a regular serial port. Best regards, Arjen PS Please do not top-post on this list. -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Richcomm Serial driver
Citeren Manzoor e Elahi manzoor.e.el...@gmail.com: I'm trying to configure my ups with nut which is a locally made one. It uses a rs232 port to talk to the computer and comes with a software called Powermanager Lite which is provided by Richcomm and supports Windows, Linux and UNIX. According to the manual it uses the Richcomm circuitry to talk to the computer and uses a drycontact protocol. Unfortunately I couldn't find any driver for Richcomm serial interface, there's a richcomm_usb however. I've tried all of the genericups drivers and the megatec driver even a USB to Serial converter cable (Prolific chipset) but no luck. Any suggestion about which driver to choose or what I'm doing wrong? If it indeed uses a dry contact interface, it is supported by the genericups driver. If not through one of the existing 'upstype' settings, you should be able to override the 'CP', 'OL', 'LB' and/or 'SD' configuration directives to make it so. This is essentially what the 'richcomm_usb' driver does for USB. I'm using NUT on FreeNAS 0.7.2 which uses NUT 2.60. Below is the link to the Richcomm product product page. Powermanager lite: http://www.richcomm.com/en/productshow.php?ippt_product_id=65 This is not a description of a dry contact interface. If this is what your UPS is using, it requires something different. Assuming the people who designed this did not create a smart protocol using the modem control lines (which would be insane, since using the TXD/RXD lines would be much simpler instead), I would say this is a smart protocol which is not supported through either genericups or richcomm_usb. The best advice we can give you is to first find out what protocol is used by the UPS (possibly by snooping the serial port when running the bundled software). Unless you have dozens of devices you have to use and/or you hourly wages are close to zero, it is probably better to ditch the UPS and buy something that is supported out of the box. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] blazer megatec drivers
Citeren Pavel Selivanov biohumanoid.li...@gmail.com:
I've being using nut 2.2.2 (Debian Lenny) via megatec_usb driver for
IPPON Back UPS 600.
Then I upgraded to nut 2.4.3 (Debian Squeeze) with broken megatec_usb.
I moved to blazer_usb, it connected IPPON.
[myups]
driver = blazer_usb
port = /dev/usb/hiddev0
desc = Local UPS
#from megatec.c: batteries[] = {{ 12.0, 9.0, 16.0, 9.7, 13.7, 0.0 },
default.battery.voltage.high=13.70
default.battery.voltage.low=9.70
Checkout the 'runtimecal' option from 'man 8 blazer' to give a
slightly better way to determine the state of charge on the UPS
(provided it reports the load).
But there are no battlow=% option available in blazer, so, I can't
change Low battery condition to be a bit more safer...
I've seen battery.charge.low option in trunk, but it seems it must
be implemented in driver, and it's not implemented in blazer.
Am I right ?
Offcourse, I can workaround this problem:
NOTIFYCMD /usr/local/sbin/check_lowbatt
/usr/local/sbin/check_lowbatt
uspc myups | grep battery.charge
res=$?
...
But it's an ugly hack...
Is there any better solution ?
I missed something ?
See 'man 8 clone' which will do just what you want. The development
version allows you to override the build in low battery detection
altogether and set your own levels.
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Belkin F6C550-AVR on Squeeze
Citeren Josu Lazkano josu.lazk...@gmail.com: Hello list, I am trying to configure Belkin F6C550-AVR UPS on a Squeeze server. I try with usbhid-ups but I get (driver(s) failed) message on service start. [...] This is my lsusb output: $ lsusb Bus 001 Device 004: ID 0665:5161 Cypress Semiconductor USB to Serial Can you help with this? I am reading lots of tutorial and howtos but there is no way to get it working. If you look in the compatibility list for Belkin, you'll find that for almost all F6Cxxx models in the list two drivers are listed. The usbhid-ups driver for = 2005 models and the blazer_usb driver for 2007 models. I suspect that the internals of your UPS have also changed in the same way. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Unable run command on notify events
Citeren GATINEAU, ANTOINE (ANTOINE) antoine.gatin...@alcatel-lucent.com: I got it working. Aparently, the script is launched as the specified user but without the environment variables. To make it work, i have defined NOTIFYCMD as following : NOTIFYCMD /bin/bah -c 'source /etc/profile ; /path/to/script/scriptname Is there a better way or is this the best way? Scripts must be self-contained. It is grievous mistake to assume anything about the environment. So it is best to follow Arnaud's advice and use absolute paths to other scripts/binaries that you need. If that's not possible, it is probably better to source /etc/profile from within the script you're running. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] NUT upgrade to 2.6.0 in Gentoo with Liebert UPS
Citeren Francesco Talamona francesco.talam...@know.eu: I was simply trying to gather more information because the running setup, the one with liebert driver and nut user, wasn't able to run anymore with the upgrade. Sorry I didn't make it clear in the first instance. I made too many tests and more than one driver get loaded in the same time. The UPS is attached only via USB, as always was, I don't have a serial connector for this device. The 'liebert' driver is for devices with a serial port. If you've run that in the past through a USB connection, there must be a USB to serial converter in the UPS. If it worked before, it must have been because the kernel added something like a /dev/ttyUSBx (or something similar) and the driver could connect to that port as if it was a regular serial port. In that case there is nothing we can do for you and you'll have to find out why this /dev/ttyUSBx port is no longer created (this isn't handled by NUT). There's still something that beats me: I checked, and the first NUT installation was in 2008 the 2.0.5 version, with this very same UPS. It could be with a different driver, but the device was always the same, always connected via USB. Since we have never supported the VID:PID combination, this was most likely with the 'liebert' driver. Is it there a compatible driver, even if not fully-featured? See above. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] NUT upgrade to 2.6.0 in Gentoo with Liebert UPS
Citeren Francesco Talamona francesco.talam...@know.eu: I have a 64 bit Gentoo, with a Liebert UPS. The last NUT working version was sys-power/nut-2.4.1-r1 (I also tried sys-power/nut-2.4.3-r2 but downgraded, don't remember the reason). [...] I don't know what else I can try, I simply don't understand what's going on. Donwgrade isn't a good option because nut-2.4.1-r1 is no more in the portage tree: it isn't impossible to install, but I prefer to make the new one work. What on earth are you trying to do? I see you're trying out both serial (liebert) and USB (usbhid-ups) connected drivers, without reference of which one worked in an earlier version. I also see that you're attempting to run multiple driver instances in parallel (most likely, unintentionally) for the same UPS. This is never a good idea. Always make sure that when you're trying things out, the leftovers from earlier experiments are stopped. Since the VID:PID combination of your UPS is not supported (not even in the development version), I suspect you've used the serial driver before. If that's the case it should still work, but most likely not if you connect the USB interface at the same time (in many cases, devices with both serial and USB share a lot of interface hardware internally). Chances are that your UPS might also work through USB, but I have never seen that before. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Cyberpower CP850PFCLCD 120% battery charge
Citeren Justin Ellison jus...@techadvise.com: Attached is a -DDD log of the driver. Did you look at it before sending it? If not, look now... :-) We need the output of both stdout and stderr: /path/to/usbhid-ups -DDD -a upsname CyberPower_CP850.log 21 The first 30 seconds worth of output should be enough. If you need anything else, let me know. See above. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Multi UPS on Debian
Citeren Márk Csaba mar...@gwyll.eu: [eaton_1] driver = blazer_usb port = 002 desc = Eaton NV 2000H vendorid = 0665 productid = 5161 bus= 003 [eaton_2] driver = blazer_usb port = 002 desc = Eaton NV 2000H vendorid = 0665 productid = 5161 bus= 004 [eaton_3] driver = blazer_usb port = 003 desc = Eaton NV 2000H vendorid = 0665 productid = 5161 bus= 004 The eaton_2 and eaton_3 devices are not uniquely identifiable. The only thing that differentiates them in ups.conf is the port, but this is not used in the device matching (it will change on reconnecting the device, so it can't be used). Basically both the eaton_2 and eaton_3 driver will attempt to connect to the same device (which will lead to a storm of connects and disconnects). Maybe i’ve miss something, but i can’t figure it out. Could someone point me to the right way? The recommended way to do use multiple USB devices, is to match the serial number of the UPS. This will make sure that if you plug the devices in a different port, the upsnames don't change. Check if the serial number is reported by the devices if you run the driver with the -DD option: /path/to/blazer_usb -DD -u root -a upsname If it is, use that instead. Note that many generic USB to serial converters don't have unique serial numbers. In that case, your only option is to make sure they are on different busses and match those. If that isn't possible either, you can't control them from the same host. Best regards, Arjen PS Unless needed, you shouldn't use the vendorid, productid and subdriver in ups.conf. Less is better here, since the additional matching that is required if you do is a waste of effort (matching regular expressions is expensive). -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Startup timing issue with CyberPower CP425HG UPS
Citeren Arun twelvefortyf...@yahoo.com: Yeap. IMO an even better option (if technically feasible) would be for the driver to try and reconnect to the UPS every few seconds. It seems to do this well if it loses connectivity after having established the initial connection, but not at all at startup. This is intentional. You don't want the system to retry forever if a driver fails to start. NUT really shouldn't be started before the USB subsystem has started. What might be wrong, is that the startup scripts may already return before the service they are starting has really started. I experienced a similar problem on an older system, where on startup the system load be so high (due to everything starting in parallel) that I had to delay starting some services manually. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Cyberpower CP850PFCLCD 120% battery charge
Citeren Charles Lepple clep...@gmail.com: in the current version of cps-hid.c, it looks like FullChargeCapacity, DesignCapacity and CapacityMode are unmapped. This is intentional. The capacity mode determines the units in which FullChargeCapacity and DesignCapacity will be reported. Generally, this will be '2' so values are reported in percent (%). In many cases they will read 100% at all times (I have yet to find a UPS where the FullChargeCapacity drops with aging batteries). Or, it could be that the firmware designers confused the RemainingCapacity value with AbsoluteStateOfCharge, which is allowed to be greater than 100%. (Pages 36-38 of the PDC spec.) That could also be the case. Given the fact that this is a highly loaded UPS (56%), it wouldn't be strange that you would need more than 81% charge left if you set the low battery level to a runtime remaining of 300 seconds. Are two -D flags sufficient to see the report descriptor information and relevant reports? With just two '-D' flags, you'll get a dump of all HID paths that are supported by the UPS. We need three '-D' flags however to see the raw report descriptor, which I would like to archive for future use. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Cyberpower CP850PFCLCD 120% battery charge
Citeren Justin Ellison jus...@techadvise.com: When I tested it out tonight, I made a point to watch the LED on the unit in comparison to the battery.charge indicator from nut. Almost instant I unplugged it, battery.charge went from 120 to 91, and immediately fell in sync with what the LED was showing. In that case, we should probably just clamp the value to 100%. Another thing is that the battery voltage doesn't seem to change at all, it is fixed at 16.0 V (due to an internal conversion factor of 2/3 that is needed on some other models). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Cyberpower CP850PFCLCD 120% battery charge
Citeren Justin Ellison jus...@techadvise.com: I have a CyberPower Systems CP850PFCLCD that I'm hooking up to NUT 2.4.3 from apt running under Ubuntu 10.04. Using the usbhid-ups driver, things *seem* to work at first glance, but there are some odd issues. The most notable issue is that the battery.charge indicator reads 120 when at full charge. I came across this post here: http://lists.alioth.debian.org/pipermail/nut-upsuser/2007-September/003222.htmlbut it looks like the user never supplied the necessary data. For whatever reason the people that made the UPS firmware decided that they didn't need to follow the USB HID PDC specifications. From the data you sent, it looks like the value for battery charge that is reported by the UPS needs some conversion (coefficient and/or offset) to get to the true battery charge. Most likely, this is present in the bundled software for the UPS, but sadly we don't know them. So unless you're going to change that, the situation is unlikely to improve. It looks like '120' means 100% charge, but one data point is not enough to find (at least) two missing parameters. The other issue that I found was that the LB flag is sent way to early when I unplugged the UPS from the outlet. I don't think so. The data you posted indicated that about the time the UPS started reporsing LB (low battery), the runtime fell below the battery.runtime.low, so this is about right. If you don't need 5 minutes to shutdown your system, you might try lowering this value (if the UPS supports that) and see if this increases the useable time on battery. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS Atlantis OnePower - VT12094S
Citeren Andrea krog...@gmail.com: Exactly what benefit can i have using the new driver with this hack? If nothing changes i can wait for nut 2.6.1 ;-) It would help to confirm that this is indeed the problem so that nut-2.6.1 will work out-of-the box for you (and all others using this model). Other than that, see 'man 8 blazer' for more information on the additional commands for this driver. The runtime estimation is something the megatec(_usb) driver didn't support for instance. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS Atlantis OnePower - VT12094S
Citeren Andrea krog...@gmail.com: * Service upsdrv starting Network UPS Tools - UPS driver controller 2.6.0 Network UPS Tools - Megatec/Q1 protocol USB driver 0.03 (2.6.0) Can't claim USB device [:]: could not detach kernel driver from interface 0: Operation not permitted Driver failed to start (exit status=1) Failed to start UPS drivers! Maybe i'm doing something wrong during compilation of the sources... Most likely, this is a permissions error from not configuring properly. For now, just fix this by running the driver as root: /path/to/blazer_usb -u root -DDD -a upsname Best regards, Arjen PS Please do not top-post on this mailing list. -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Information required for adding a ups to the compatibility list
Citeren Garðar Arnarsson gar...@giraffi.net: Just wondering what information is required for adding a ups to the compatability list... Is upsc output enough? No, we also need to know if the UPS supports shuts down automatically, both when on mains and on battery. To check this, issue the upsmon -c fsd command from the upsmon master system, first with and then without mains present. In the first case, the UPS should cycle the power and in the second wait until the power returns. You'll want to make sure all systems powered from the UPS are ready to lose power. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS Atlantis OnePower - VT12094S
Citeren Andrea krog...@gmail.com:
0.257887 Trying megatec protocol...
0.257901 send: Q1
0.506931 blazer_status: short reply
0.506950 Status read 1 failed
Sadly there is a small flaw in the krauler subdriver here and it
doesn't output the data it has read from the UPS. But since it doesn't
report a failure here, it means that it has successfully read
something. Add the fact that the megatec_usb driver was able to talk
to your UPS probably means that it returns 46 bytes in the reply
(sufficient for megatec_usb) and not 47 (which is required by
blazer_usb). Most likely, the terminating '\r' which is expected is
not part of the reply. I've made it optional in the development
version, so it will be in the next released version. If you're able to
build from sources, you can modify line 189 in drivers/blazer.c from
if (blazer_command(cmd, buf, sizeof(buf)) 47) {
to
if (blazer_command(cmd, buf, sizeof(buf)) 46) {
and compile the driver again. Otherwise, running the megatec_usb
driver from nut-2.4.3 is the only alternative.
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS Atlantis OnePower - VT12094S
Citeren Andrea krog...@gmail.com: Some output with blazer_usb: * Service upsdrv starting Network UPS Tools - UPS driver controller 2.6.0 Network UPS Tools - Megatec/Q1 protocol USB driver 0.03 (2.6.0) No supported UPS detected Driver failed to start (exit status=1) Failed to start UPS drivers! [ !! ] * ERROR: upsdrv failed to start Start the driver again, now with debugging enabled: /path/to/blazer_usb -DDD -a upsname Assuming the detection will fail, just post the full output from the above command here. Just to be sure, post the output of lsusb -v as well. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Help with Aiptek PowerWalker VFI 1000 LCD and Konig CMP1200
Citeren Espen Berg es...@halden.by: I have just installed nut_2.6.0 from Debian testing, do anyone know the correct driver for this ups? The blazer_usb don't report battery-charge, the bundled software report charge and runtime. The UPS doesn't report battery charge and/or runtime. See the paragraph BATTERY CHARGE in 'man 8 blazer' for more information. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] libusb_get_interrupt: error reading from interrupt endpoint /dev/ugen0.1
Citeren John Bayly freebsd.po...@tipstrade.net: Thanks for pointing that out. Just did some timing and found that with and without the pollonly flag set, the ups.load value was changing when applying and removing additional load. I did however notice that the time taken to register the load change could be between 0 and 20 seconds, thought this could be down to the UPS itself, and not the drivers. I've seen no errors being reported, so I'll cross my fingers! Note that only a handful variables (mostly related to critical ups.status flags) will be polled every 'pollinterval' (default: 2) seconds (for the mge-hid subdriver) and the remainder of the variables only once every 'pollfreq' (default: 30) seconds. See 'man 5 ups.conf' and 'man 8 usbhid-ups' respectively. So with the 'pollonly' flag set, the OL/OB/LB and *.timer variables will be updated every 2 seconds and the remainder every 30 seconds. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] blazer_usb for SVEN Power Pro+ 500 USB
Citeren Arnaud Quette aquette@gmail.com: can you please send us an upsc output? Not really needed. The richcomm_usb driver supports only 'ups.status' since the UPS is essentially a glorified contact closure device. Have you also tested for shutdown, and upsrw / upscmd supported data? Testing the shutdown function would be a really good idea. Note that it probably won't shutdown unless running on battery. There are no parameters which can be set and the driver doesn't support instcmds either. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] blazer_usb for SVEN Power Pro+ 500 USB
Citeren Sergey Talchuk tals1...@gmail.com: 2. lsusb output Bus 002 Device 001: ID : Bus 002 Device 002: ID 0925:1234 Lakeview Research Your UPS might be supported by the 'richcomm_usb' driver. It is most certainly not supported by the 'blazer_usb' driver. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with usbhid-ups and CyberPower CP1500 on 2.6.0
Citeren Charles Lepple clep...@gmail.com: Arjen: do we actually have any cases of reports larger than 8 bytes? Yes. At least the MGE Evolution series uses reports that are larger than 8 bytes. If so, should we mark this as a quirk for CyberPower devices? Well, I still don't understand why we can't read with an arbitrary buffer length in the libusb call in the first place. This should be handled by the library (not the application). Also, it seems like we need to distinguish between returning 0 and 0 from the libusb call. Currently, we are reading errno when a zero-length packet is being read. This too is broken. If we attempt to read a report and libusb can't return any data, it should at least give us a hint why. I really feel that this should be handled by the library, not NUT. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with usbhid-ups and CyberPower CP1500 on 2.6.0
Citeren Charles Lepple clep...@gmail.com: If I run it under strace, the ioctls on the /dev/bus/usb file descriptor preceeding each operation not permitted error return 0, not an error code such as EPERM. That seems strange. Would you please compress and send the strace output (without -u root)? Attached. Looks like Ubuntu fixed 2.4.3 here: https://bugs.launchpad.net/ubuntu/+source/nut/+bug/572262 That was committed to NUT here: http://trac.networkupstools.org/projects/nut/changeset/2407 This breaks reading larger reports, so it was reverted: http://trac.networkupstools.org/projects/nut/changeset/2719 This patch (committed after 2.6.0 was released) claims to restore 2.4.1 behavior: http://trac.networkupstools.org/projects/nut/changeset/2893 All of the above are irrelevant here. The driver runs fine when started as root, so this must be a permissions problem. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Driver for AEG UPS
Citeren Armin Barth armin.ba...@pumpen-barth.de: Hallo, I'm loocking for a driver to connect a AEG UPS Protection A 1500 mit nut. The Error-massage is this: Network UPS Tools - UPS driver controller 2.6.0 Network UPS Tools - Generic HID driver 0.35 (2.6.0) USB communication driver 0.31 This Liebert device (06da:0003) is not (or perhaps not yet) supported by usbhid-ups. Please make sure you have an up-to-date version of NUT. If this does not fix the problem, try running the driver with the '-x productid=0003' option. Please report your results to the NUT user's mailing list nut-upsuser@lists.alioth.debian.org. No matching HID UPS found Driver failed to start (exit status=1) My everyboddy help me? Try the blazer_usb driver instead. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Support for FSP EP1000
Citeren Brian Read bri...@bjsystems.co.uk: Am Trying to use nut (2.2.0 - on an SMEServer V8 aka Centos 5.5) on the above UPS, I've tried the megatec driver in serial and USB mode (the device has both types of connection), but no success. The version of NUT you're using is almost four years old and well past its 'use by' date. [...] I can see from the website that the blazer driver has taken over from the megatec on, but I don't seem to have it. Anyone any ideas? Upgrade to a more recent version of NUT. The current version is nut-2.6.0. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] problem starting upsd
Citeren James bjloc...@lockie.ca: $ sudo /usr/sbin/upsd - Network UPS Tools upsd 2.4.3 0.00 listen_add: added ::1:3493 0.84 listen_add: added 127.0.0.1:3493 0.000102 setuptcp: try to bind to 127.0.0.1 port 3493 0.000185 listening on 127.0.0.1 port 3493 0.000204 setuptcp: try to bind to ::1 port 3493 0.001328 setuptcp: socket: Address family not supported by protocol 0.001381 not listening on ::1 port 3493 Apparently the version of NUT you're using was built on a system that had IPv6 enabled and yours doesn't. Adding LISTEN 127.0.0.1 to 'upsd.conf' should fix this. See also 'man 5 upsd.conf'. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Access restriction on Upgrade Debian lenny - Debian squeeze
Citeren Lukas Haase lukasha...@gmx.at: I somehow tried both but it does somehow not work as expected. When I add ups : ALL upsd : ALL to hosts.deny, then no communication should be possible. However, I can access the statistics from another host running upsstats.cgi! I also tested with upsc denchi@localhost - it always works! The documentation says that this tcp-wrappers is only used for commands that require to be logged in to the UPS. Since upsc and upsstats don't require a login, this will be passed through. There is not much point in trying to prevent this (see the mailinglist archives). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with upscmd ACCESS-DENIED
Citeren Garðar Arnarsson gar...@giraffi.net: I have defined the user in the /etc/ups/upsd.users 74 [gardar] 75 password = hidden 76 allowfrom = local 77 actions = SET 78 instcmds = ALL 79 [local_mon] 80 password = hidden 81 allowfrom = localhost 82 upsmon master Device and driver info: device.mfr: Inform device.model: SINUS1KURM device.type: ups driver.name: blazer_ser driver.version: 2.6.0 driver.version.internal: 1.51 What am I doing wrong? Did you check your syslog lately? The 'allowfrom' keyword is no longer used (since a couple of versions actually) and has been replaced by tcp-wrappers, which most likely is compiled in the version you're using. If there is a blanket 'deny all' in /etc/hosts.allow, this requires you to setup access permissions through /etc/hosts.allow. See the UPGRADING document, 'man 8 upsd' and 'man 5 hosts_access'. Adding something like upsd : garder@localhost : ALLOW should work. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with upscmd ACCESS-DENIED
Citeren Garðar Arnarsson gar...@giraffi.net: Thanks a bunch, that worked like a charm :) Glad to hear that. But now I've got another question... After I run commands (tests) with upscmd, where do I see the results? You don't. Ran a battery test check and it did not give any output. Only if the UPS finds that the battery needs to be replaced it will report the 'RB' status (replace battery). If it doesn't, all is well. The Q1 protocol that is used by your UPS doesn't support more verbose messages (and neither does it report runtime or charge capacity) so there is nothing more to report. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] PowerShield Centurion 2000
Citeren James Cameron qu...@laptop.org: # upscmd myups load.on Username (root): Password: # It didn't turn on. What's this username and password? How should I know? (man 5 upsd.users) Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problem using an Eaton Ellipse ASR 750 VA on FreeBSD
Citeren Frederic Praca frederic.pr...@freebsd-fr.org: I wondered how the USB UPS are detected and if my UPS is described in the source code. Any idea of where I should take a look ? We search for a VendorID / ProductID combination. The one you posted earlier idVendor = 0x0463 idProduct = 0x is one of the combinations that are supported by the usbhid-ups driver (it is used for all MGE / Eaton devices with USB HID PDC support). If the driver can find this ID in the list of attached devices, it should find it. But I guess this is something related to the FreeBSD USB stack, which I know nothing of. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problem using an Eaton Ellipse ASR 750 VA on FreeBSD
Citeren frederic.pr...@free.fr: I have to manage an Eaton Ellipse ASR 750 VA UPS under a FreeBSD 8.2 server. I used nut from ports collection but I'm unable to detect the UPS by USB cable. [...] Any idea of how to make it works ? Did you follow the FreeBSD installation HOWTO that's mentioned in the documentation? http://people.freebsd.org/~thierry/nut_FreeBSD_HowTo.txt Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Ubuntu server won't restart
Citeren Erik Hjertén e...@hjerten.com: I'm quite stuck now so any pointers on how to troubleshoot is most appreciated. The first thing to check is whether or not the UPS receives the shutdown command. Power your system from an alternative source (this is important!) and run the command /path/to/usbhid-ups -k -a UPS This signals the UPS to cycle the output (if mains is present) or shutdown the output and wait for the power to return (if not). Look at the console for messages that are displayed. If the above works (both with and without mains present), there probably is an issue with running this command late in the system halt script. This is something the people from Ubuntu should be able to help you with. If it doesn't work, come back here for more help. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] [Nut-upsdev] Bug/Patch for NUT 2.6.0 ; usbhid-ups (libhid.c)
Citeren Carsten Burkhardt c.burkha...@b-c-s.de: Do you mean such unsuccessfully test with new hardware same like attached file explore.txt? No. We're specifically looking for people that have access to UPS systems that are known to be supported by existing versions of NUT, to verify that new releases still support them. Your UPS doesn't seem to match the 'known to be supported' condition. The VID:PID combination doesn't match any of the supported models. The USB interface has a VID of Phoenixtec Power Co, but other than telling us that it probably is some proprietary USB to serial converter, doesn't help us really much. If it is recognized by the kernels usbserial module, chances are that you can use one of the serial drivers with it. Best regards, Arjen PS This is a subscription only mailing list. -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] upsd crashes with a broken pipe error
Citeren Zach La Celle lace...@roboticresearch.com: On the Dell server, the MpMemory testing all passed. It doesn't seem to be a physical problem with the memory on the machine. I also ran some other basic diagnostics on the disk drives, cache, and the rest of the system, and it all passed as well. Any further ideas? As a last resort, running the upsd server in 'valgrind' could be useful, but only if the error occurs shortly after startup. You'll have to run it with -D though, to prevent it from backgrounding. What remains weird is that you seem to be the only one that has this problem. I've run upsd in valgrind for days on end and have not seen any memory problems after that. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] upsd crashes with a broken pipe error
Citeren Zach La Celle lace...@roboticresearch.com:
You can see where the problem happens in parseconf.c, on line 125
with the code:
/* resize the lists */
ctx-arglist = realloc(ctx-arglist,
sizeof(char *) * ctx-numargs);
With the given arguments, this boils down to
ctx-arglist = realloc(NULL, sizeof(char *));
This is all normal. Upon the first invocation of add_arg_word,
ctx-arglist will be a NULL pointer (since there is nothing in the
list yet). This should then allocate a one element array of a pointer
to char (to store the
If ptr is a null pointer, realloc() shall be equivalent to malloc()
for the specified size.
After that, all hell breaks loose, but that's out of our control.
There is a slight problem in lines 131-132
ctx-argsize = realloc(ctx-argsize, sizeof(int *) * ctx-numargs);
which should really read
ctx-argsize = realloc(ctx-argsize, sizeof(size_t) * ctx-numargs);
but I doubt that sizeof(size_t) will be smaller that sizeof(int *), so
this just wastes a few bytes of memory.
This also might help:
(gdb) p *ctx
$4 = {f = 0x0, state = 5, ch = 9, arglist = 0x0, argsize = 0x0,
numargs = 1, maxargs = 1, wordbuf = 0x61f2e0 Z, wordptr = 0x61f2fd
, wordbufsize = 16, linenum = 0, error = 0, errmsg = '\000'
repeats 255 times, errhandler = 0, magic = 7497264, arg_limit =
32, wordlen_limit = 512}
None of these values is suspect.
If I go up in GDB to the pconf_char function, here is the
character which is killing it:
(gdb) p ch
$6 = 9 '\t'
This is expected. Any whitespace character ends the collection of
characters for the current argument and will start a new one. Nothing
out of the ordinary. If it was, 100% of the NUT installations would
suffer the same problems as you're seeing 100% of the time they start
the upsd server. This is not the case and even in your case, the
problem seems to occur intermittently, which is more an indication
you're either running out of memory or the system is suffering from
bad memory. Did you run a memory check lately?
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] hardware compatibility list
Citeren Ernest Sales ersa...@gmail.com: N.B.: the blazer_usb driver recognized the device, but logs showed connection loss about every minute, so I didn't do further trying. This is a known problem in nut-2.4.3 and should be solved in nut-2.6.0. We have also dropped the megatec and megatec_usb drivers, so it is probably a good idea to check out the newer release. If that version doesn't work for you, let us know. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] nut unable to communicate with new APC SMX100 over USB
Citeren Brian Daniels bitm...@pobox.com:
upshid-ups is unable to communicate with the UPS, giving 'Protocol
error'. I've also tried the snapshot and 2.7 svn release with the
same results. Debug output is below, any ideas appreciated.
Could you try if the attached patch makes any difference? We've seen
other reports from people having trouble communicating with their
UPSes. It is also in the development version, so if it is more
convenient to run that, this should be fine.
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
--- drivers/libhid.c 2011-01-15 21:03:53.149154167 +0100
+++ drivers/libhid.c 2011-02-11 10:10:02.529935413 +0100
@@ -141,7 +141,6 @@
{
int id = pData-ReportID;
int r;
- unsigned char buf[SMALLBUF];
if (rbuf-ts[id] + age time(NULL)) {
/* buffered report is still good; nothing to do */
@@ -149,17 +148,14 @@
return 0;
}
- r = comm_driver-get_report(udev, id, buf, sizeof(buf));
+ r = comm_driver-get_report(udev, id, rbuf-data[id], rbuf-len[id]);
if (r = 0) {
return -1;
}
- /* broken report descriptors are common, so store whatever we can */
- memcpy(rbuf-data[id], buf, (r rbuf-len[id]) ? r : rbuf-len[id]);
-
if (rbuf-len[id] != r) {
upsdebugx(2, %s: expected %d bytes, but got %d instead, __func__, rbuf-len[id], r);
- upsdebug_hex(3, Report[err], buf, r);
+ upsdebug_hex(3, Report[err], rbuf-data[id], r);
} else {
upsdebug_hex(3, Report[get], rbuf-data[id], rbuf-len[id]);
}
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin bakd...@gmail.com: Yes, that does the trick! # clients/upscmd -u apcmon -p pass123 apc1500 shutdown.return has the desired effect. Good. I assume you tried this on the CS-500, right? Do you have any idea how long the delay is before the device actually shuts down? Would you like me to provide any more output? It would be nice to know under what conditions you tested this command. We would like to see what happens both with and without mains present at the time of running this command. I both work as expected, we may have found a workable solution. I do have to check the report descriptors of some other APC devices, to check if we're not shooting ourselves in the foot by adding this (to see if there may be conflicts with other known devices). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin bakd...@gmail.com: On power: Switches immediately to battery Waits 60 seconds Sleeps for 2 seconds, switches output power off Restarts Although it is a bit weird that the device switches to battery, this doesn't really harm. We know such behavior from older devices with 'dumb' contact closure serial interfaces, which can only be shutdown when running on battery. On battery: Waits 60 seconds Sleeps When power returns, restarts. That's good to know. It looks like we found the correct mapping. If this doesn't conflict with known report descriptors, I'll add this to the development version later today. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Plexus 800VA UPS on ReadyNAS Duo
Citeren Mike Barber badpa...@googlemail.com: Installed 2.4.1 using apt and installed in place of initial version Found various web documents detailing that blazer_usb would probably be the driver to use. using usb.conf : [UPS] driver = blazer_usb port = auto and running the driver in debug mode gives the following : [...] Checking device (0001/) (001/003) - VendorID: 0001 - ProductID: - Manufacturer: ATCL FOR UPS - Product: ATCL FOR UPS - Serial Number: ATCL FOR UPS The VendorID / ProductID combination is bogus. The manufacturer of the UPS was too cheap to apply for a real USB ID and made one up. This means that this will give us no clue how to communicate with this device based on this information. A few years ago we ran into this combination for the first time and at that time we found out how to talk to that particular device. However, this doesn't mean that yours will work in the same way (it may be something completely different, there is no way to tell). There is a very small chance that one of the other subdrivers in blazer_usb is able to talk to device. You'll have to help finding it by specifying 'vendorid', 'productid' and 'subdriver' in ups.conf. See 'man 8 blazer' for more information. If this also fails to detect your UPS you're basically out of luck. Unless *you* can provide us with the protocol this device uses (ask the vendor, manufacturer, reverse engineer it, whatever), we can't support it in NUT. using Blazer_usb on 2.6 gives virtually the same output as 2.4.1 You'll definitely need to use this one for the above to have any chance of success. Good luck. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin bakd...@gmail.com:
On 06/02/2011 21:42, Kevin wrote:
Ok, I've tried that. The result of clientcmd -u apcmon -p pass123
-a apc1500 shutdown.reboot is nothing. Nothing that I can see
changes at all.
Of course. Do as I asked you and it *will* make a difference.
I did this with the old working modified hidups driver:
# ./hidups -DDD -k /dev/hiddev0
Network UPS Tools: HID UPS driver 0.13 (2.0.0)
Use nut-2.6.0 instead. The above version is too old and I have no idea
what variables it supports (and I don't want to take the time finding
out).
There are three lines in the apc-hid.c code that reference shutdown.reboot:
1. { shutdown.reboot, 0, 0, UPS.PowerSummary.DelayBeforeReboot,
NULL, 10, HU_TYPE_CMD, NULL },
2. { shutdown.reboot, 0, 0, UPS.Output.DelayBeforeReboot, NULL,
10, HU_TYPE_CMD, NULL },
3. { shutdown.reboot, 0, 0,
UPS.APCGeneralCollection.APCDelayBeforeReboot, NULL, 1,
HU_TYPE_CMD, NULL },
The name change of the command is critical here. NUT will use whatever
mapping it finds first, so that's the reason I asked you to use
'shutdown.return' for this specific HID path instead. Otherwise the
command will never be reached if you call the driver with '-k' and
when you run 'shutdown.reboot' it will probably find a different HID
path first.
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin bakd...@gmail.com:
Ok. Thanks. The order of the code is now:
{ shutdown.reboot, 0, 0,
UPS.APCGeneralCollection.APCDelayBeforeReboot, NULL, 1,
HU_TYPE_CMD, NULL },
{ shutdown.reboot, 0, 0, UPS.PowerSummary.DelayBeforeReboot,
NULL, 10, HU_TYPE_CMD, NULL },
{ shutdown.reboot, 0, 0, UPS.Output.DelayBeforeReboot, NULL,
10, HU_TYPE_CMD, NULL },
and the output of usbhid-ups -a apc1500 -k -DDD CS500shutdown.txt
21 is attached.
(No visible change)
Of course not. When do you start listening to my advice? :-(
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin bakd...@gmail.com: There is no call for language like that. I've spent a huge amount of time in the last six weeks trying to sort this problem with your code. This is not *my* code. I'm just trying to help here. I would be more than happy to ditch the APC support from NUT entirely, but due to popular demand this is just not an option. I'll go and find other alternatives if you take that attitude. Whatever. I have better things to do too with my free time. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Status OB (on battery) when polling a Liebert PSA
Citeren Pier Paolo Glave pierpaolo.gl...@gmail.com: Yes! The results are quite different now :) That's good to know. This is the result of upsc now, when AC power is plugged in: battery.charge: 100 battery.type: PbAc battery.voltage: 28 battery.voltage.nominal: 2 device.mfr: Emerson Network Power device.model: LiebertPSA device.serial: device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.6.0 driver.version.data: Liebert HID 0.3 driver.version.internal: 0.35 ups.mfr: Emerson Network Power ups.model: LiebertPSA ups.productid: 0001 ups.serial: ups.status: OL CHRG ups.vendorid: 10af Looking at the debug output you sent earlier, it looks like your UPS might support some other variables too. Could you please post some similar output as you did recently, now with these patches included? And, if I unplug the AC power, the following parameter changes: ups.status: OB DISCHRG That looks promising. Thank you Arjen: you gave me a good support, in a very short time. I'm ready now to go on with NUT configuration: I think I'm able now to have a controlled PC shutdown. I'll let you know how it goes. That's also something I would be interested in. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin bakd...@gmail.com: You could have perhaps made a point of the sudden change to a different command. Others also missed this subtlety. I posted the 'old' and 'new' lines. You might have missed this on the first look, buy after I told you the difference, you could have looked again at the original post. You miss the point entirely. I am giving you code that works, whereas yours does not. Surely a programmers dream. Not at all. As I already indicated a couple of times, APC uses a myriad of methods to shutdown their UPSes. Have a look at the USB apcupsd code and you'll appreciate how broken the APC software is. So bluntly accepting your changes might have fixed you problems, but would at the same time break it again for others. This is the problem we're in (which you don't seem to understand). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin bakd...@gmail.com: Exactly. I am beginning to see a 'broken firmware' pattern here. The above is the only reason why we need multiple HID subdrivers in usbhid-ups. If every UPS vendor would care to implement (and properly test!) their firmware, we would need exactly one subdriver that would fit all USB HID Power Device Class UPS'es. But since many contain bugs (and sometime conflicting implementations) we need one for almost every vendor. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] hardware compatibility list
Citeren Ernest Sales ersa...@gmail.com: I would like to report a working device to add to the hardware compatibility list, but cannot find a way on the website. Would this list be OK for that purpose? Sure. Please list the output of 'upsc' as well as whether or not you tested the shutdown function of the UPS. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin bakd...@gmail.com:
You are quite right! I now have this line in apc-hid.c:
{ shutdown.return, 0, 0,
UPS.APCGeneralCollection.APCDelayBeforeReboot, NULL, 1,
HU_TYPE_CMD, NULL },
and get this result:
# clients/upscmd -u apcmon -p pass123 apc1500 shutdown.return
Unexpected response from upsd: ERR CMD-NOT-SUPPORTED
I have attached the output of usbhid-ups -a apc1500 -k -DDD
CS500shutdown.txt 21 in case it is of value.
It is of value. The HID path I sent was wrong (it isn't in the above
listing, so usbhid-ups will not find it). There is no
APCGeneralCollection in your UPS. Instead of
{ shutdown.return, 0, 0,
UPS.APCGeneralCollection.APCDelayBeforeReboot, NULL, 1,
HU_TYPE_CMD, NULL },
the correct HID path should be
{ shutdown.return, 0, 0, UPS.Output.APCDelayBeforeReboot,
NULL, 1, HU_TYPE_CMD, NULL },
Sorry about that.
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin bakd...@gmail.com:
Seems to have gone a bit quiet. Are we at a dead end now?
No, I just don't have a lot of spare time on my hand lately. You could
try if changing
{ shutdown.reboot, 0, 0,
UPS.APCGeneralCollection.APCDelayBeforeReboot, NULL, 10,
HU_TYPE_CMD, NULL },
to
{ shutdown.return, 0, 0,
UPS.APCGeneralCollection.APCDelayBeforeReboot, NULL, 1,
HU_TYPE_CMD, NULL },
helps. Looking in the apcupsd sources seems to indicate that this
isn't a timer at all, but instead just a flag that forces a reboot
cycle.
Given the brokenness of the APC HID PDC implementation (the apcupsd
project uses about half a dozen ways to shutdown), I doubt that the
support status of APC is going to improve a lot. If you have not
already tried the apcupsd project, I'd suggest to try that too. Since
NUT is not focussed on one specific make, we probably can never give
the same support. This is also due to the fact that none of the active
developers has access to one of these devices.
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Status OB (on battery) when polling a Liebert PSA
Citeren Pier Paolo Glave pierpaolo.gl...@gmail.com: Everything seems to be fine, except that, when I run upsc liebert@localhostups.status, it retuns OB, even if the UPS is currently online. Looking at the rejected earlier message, I'd say you have a Belkin OEM device that has a very broken report descriptor. You may want to checkout the recently released nut-2.6.0 version. But I'm almost certain that the fixes in the HID parser are not going to solve this problem and that instead the problem is in the UPS itself. We may or may not be able to work around this, but in that case we will need lots of support from you (and you must be willing/capable to run the development version too). [...] I would like to paste also a complete tracing of /lib/nut/usbhid-ups -D -a liebert, but the message would become too big. Then use gzip to compress it before attaching. We really need the full listing as an attachment, not inline in a message. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Feedback for Powercom IMD1000 AP with 2.6.0
Citeren Mehmet Giritli mgiri...@giritli.eu: Here you go. Thanks! This looks like a different model than the existing ones. Sadly, it seems to be just as broken as previous models... :-( One more thing. Does this ups support reporting temperature? Can you tell this by looking at the log file I sent? Current NUT driver does not seem to find this data. Yes and no. Although the UPS lists this in the report descriptor (the list of supported variables), it miserably fails when we try to read it: 0.219124 libusb_get_report: error sending control message: Operation not permitted 0.219149 Can't retrieve Report 2c: Operation not permitted 0.219165 Path: UPS.PowerSummary.Temperature, Type: Feature, ReportID: 0x2c, Offset: 0, Size: 8 I am not an expert on this, but it seems there is some data for temperature. All lines where you see 'Operation not permitted' are variables that are supposed to be readable from the UPS, but when we do so, fail to return an answer. There is nothing we can do about this. The firmware in the UPS is broken, so we can't read these values. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin bakd...@gmail.com: Different # ./clients/upsc apc1500 [...] ups.delay.shutdown: 90 ups.delay.start: 250 This is what I expected to happen. The value of ups.delay.shutdown is now read from the UPS... ./clients/upsrw -s ups.delay.shutdown=30 -u apcmon -p pass123 apc1500 OK # ./clients/upsc apc1500 [...] ups.delay.shutdown: 30 ups.delay.start: 250 ..and apparently can be written as well. Sadly, it looks like this value is used for a different purpose than setting the minimum delay value before shutdown (like I expected). Unless you're willing to dig deeper into this, I think we have to conclude that this model doesn't allow setting the delay values lower than 90 seconds. Using an 'ondelay' value of 100, does the UPS cycle the output if mains is present? And does it wait until the mains return if it is not present? I would still like to see the full output of the below command. An earlier version you posted was incomplete (the report descriptor was missing, which is vital to be able to check our HID parser without access to a specific UPS model). Could you please post the output of /path/to/usbhid-ups -DD -a apc1500 APC_Smart-UPS_1000.log 21 here? The redirection of stderr to stdin was probably missing in your previous post. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin bakd...@gmail.com: ./clients/upsrw -s ups.delay.shutdown=30 -u apcmon -p pass123 apc1500 OK # ./clients/upsc apc1500 [...] ups.delay.shutdown: 30 ups.delay.start: 250 ..and apparently can be written as well. Yes, but this value could also be changed before the patches. (See previous posts) Not in the same way. I'm not really interested in what NUT thinks about this value, it is where it is stored. Previously, this value would be a driver side variable (without the UPS ever knowing we changed it) while in this case, it is a value stored (and modified) in the UPS. I was hoping that the UPS would consider this value for the minimum shutdown delay, but apparently it doesn't. Chances are it is something completely different... :-( Happy to dig as deep as you would like me to. (I would like to get the CS 500 sorted out too though) I will check again with the unmodified code, but I'm fairly sure that the output will cycle when power is present. (even with on and offdelay values at the default 90 minimum) That's even weirder... I would still like to see the full output of the below command. An earlier version you posted was incomplete (the report descriptor was missing, which is vital to be able to check our HID parser without access to a specific UPS model). Could you please post the output of /path/to/usbhid-ups -DD -a apc1500 APC_Smart-UPS_1000.log 21 here? The redirection of stderr to stdin was probably missing in your previous post. I'll do it now and attach it here. Sorry about that, the report descriptor is only reported at debug level 3 (or higher). So I need the output of the below command instead: /path/to/usbhid-ups -DDD -a apc1500 APC_Smart-UPS_1000.log 21 Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Plexus UPS on a QNAP NAS
Citeren Jonathan Cunliffe subscript...@gadget.org.uk: [...] Anyone any ideas...? Someone posted a reply to your first message. Instead of reposting the same message, you might try if following that reply might get you further. Reading the manuals might also help. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin bakd...@gmail.com: Sorry about that, the report descriptor is only reported at debug level 3 (or higher). So I need the output of the below command instead: /path/to/usbhid-ups -DDD -a apc1500 APC_Smart-UPS_1000.log 21 Here it is. Much better, thanks! Could you do the same for the CS-500 (time permitting). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin bakd...@gmail.com:
Happy to dig as deep as you would like me to. (I would like to get
the CS 500 sorted out too though)
I think the only solution I can come up with to support (?) all known
APC models, is to not map the HID paths to 'load.on.delay' and to rely
on the UPS to provide a grace period before cycling the power or
shutting down.
Can you try the attached patch on the pristine nut-2.6.0 sources and
let us know if both APC models you own, shutdown and restart properly?
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
--- drivers/apc-hid.c (revision 2849)
+++ drivers/apc-hid.c (working copy)
@@ -339,17 +339,17 @@
/* USB HID PDC defaults */
{ load.off.delay, 0, 0, UPS.PowerSummary.DelayBeforeShutdown, NULL, DEFAULT_OFFDELAY, HU_TYPE_CMD, NULL },
- { load.on.delay, 0, 0, UPS.PowerSummary.DelayBeforeStartup, NULL, DEFAULT_ONDELAY, HU_TYPE_CMD, NULL },
+ /* { load.on.delay, 0, 0, UPS.PowerSummary.DelayBeforeStartup, NULL, DEFAULT_ONDELAY, HU_TYPE_CMD, NULL }, */
{ shutdown.stop, 0, 0, UPS.PowerSummary.DelayBeforeShutdown, NULL, -1, HU_TYPE_CMD, NULL },
{ shutdown.reboot, 0, 0, UPS.PowerSummary.DelayBeforeReboot, NULL, 10, HU_TYPE_CMD, NULL },
/* used by APC SmartUPS RM */
{ load.off.delay, 0, 0, UPS.Output.DelayBeforeShutdown, NULL, DEFAULT_OFFDELAY, HU_TYPE_CMD, NULL },
- { load.on.delay, 0, 0, UPS.Output.DelayBeforeStartup, NULL, DEFAULT_ONDELAY, HU_TYPE_CMD, NULL },
+ /* { load.on.delay, 0, 0, UPS.Output.DelayBeforeStartup, NULL, DEFAULT_ONDELAY, HU_TYPE_CMD, NULL }, */
{ shutdown.stop, 0, 0, UPS.Output.DelayBeforeShutdown, NULL, -1, HU_TYPE_CMD, NULL },
{ shutdown.reboot, 0, 0, UPS.Output.DelayBeforeReboot, NULL, 10, HU_TYPE_CMD, NULL },
/* used by APC BackUPS ES */
{ load.off.delay, 0, 0, UPS.APCGeneralCollection.APCDelayBeforeShutdown, NULL, DEFAULT_OFFDELAY, HU_TYPE_CMD, NULL },
- { load.on.delay, 0, 0, UPS.APCGeneralCollection.APCDelayBeforeStartup, NULL, DEFAULT_ONDELAY, HU_TYPE_CMD, NULL },
+ /* { load.on.delay, 0, 0, UPS.APCGeneralCollection.APCDelayBeforeStartup, NULL, DEFAULT_ONDELAY, HU_TYPE_CMD, NULL }, */
{ shutdown.stop, 0, 0, UPS.APCGeneralCollection.APCDelayBeforeShutdown, NULL, -1, HU_TYPE_CMD, NULL },
{ shutdown.reboot, 0, 0, UPS.APCGeneralCollection.APCDelayBeforeReboot, NULL, 10, HU_TYPE_CMD, NULL },
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin bakd...@gmail.com:
#define APC_HID_VERSION APC HID 0.95-patch2
[...]
{ ups.delay.shutdown, ST_FLAG_RW | ST_FLAG_STRING, 10,
UPS.Output.APCShutdownAfterDelay, NULL, %.0f,
HU_FLAG_QUICK_POLL, NULL },
I see my error now. The above line should be moved up to before the
first occurence of { ups.delay.shutdown, ... }. The first available
HID path that is found, will set the NUT mapping and there is one
before this line now, so the above will never be used in its present
location.
The ups.delay.shutdown value starts at what is set in the ups.conf (1):
This should have tipped me off. The 'offdelay' should be ignored by
the driver if the above line is in the correct location.
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin bakd...@gmail.com: I'm posting the debug file again in case it gives any more clues. I modified the version number to make sure I was actually using the patched driver. I don't know, but these lines may be significant: # grep Value: 90 APC-1000.patched.txt 1.397898 Path: UPS.Output.APCShutdownAfterDelay, Type: Input, ReportID: 0x26, Offset: 0, Size: 16, Value: 90 1.397898 Path: UPS.Output.APCShutdownAfterDelay, Type: Feature, ReportID: 0x26, Offset: 0, Size: 16, Value: 90 Does this mean the value has not changed? Sorry for the confusion. Yes the value hasn't changed, but I didn't expect that to happen. It should however be modifiable through 'upsrw', so that you might be able to set it to a lower value. In the usbhid-ups driver, the 'ups.delay.(start|shutdown|reboot)' values are driver variables. They are only send to the UPS when you initiate the corresponding command. However, on the APC it seems to be possible (mandatory) to store them in the UPS itself. So try if you can change this value through upsrw to something like 20 seconds and lower the 'offdelay' value to 30 seconds. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin bakd...@gmail.com:
[...]
but doesn't affect the initial value of ups.timer.shutdown (90)
after the shutdown.return command:
# ./clients/upscmd -u apcmon -p pass123 apc1500 shutdown.return
OK
# ./clients/upsc apc1500
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.mfr.date: 2007/07/07
battery.runtime: 5880
battery.runtime.low: 120
battery.temperature: 32.4
battery.type: PbAc
battery.voltage: 27.0
battery.voltage.nominal: 24.0
device.mfr: American Power Conversion
device.model: Smart-UPS 1000
device.serial: AS0727233122
device.type: ups
driver.name: usbhid-ups
driver.parameter.offdelay: 1
driver.parameter.ondelay: 250
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.0
driver.version.data: APC HID 0.95-patched
driver.version.internal: 0.35
input.sensitivity: high
input.voltage: 230.4
output.voltage: 229.6
output.voltage.nominal: 230.0
ups.beeper.status: disabled
ups.delay.shutdown: 30
ups.delay.start: 250
ups.firmware: 652.13.I
ups.firmware.aux: 7.3
ups.load: 5.8
ups.mfr: American Power Conversion
ups.mfr.date: 2007/07/07
ups.model: Smart-UPS 1000
ups.productid: 0002
ups.serial: AS0727233122
ups.status: OL
ups.test.result: No test initiated
ups.timer.reboot: -1
ups.timer.shutdown: 82
ups.timer.start: 242
ups.vendorid: 051d
Could you try this again with
{ ups.delay.shutdown, ST_FLAG_RW | ST_FLAG_STRING, 10,
UPS.Output.APCShutdownAfterDelay, NULL, %.0f, HU_FLAG_SEMI_STATIC,
NULL },
changed to
{ ups.delay.shutdown, ST_FLAG_RW | ST_FLAG_STRING, 10,
UPS.Output.APCShutdownAfterDelay, NULL, %.0f, HU_FLAG_QUICK_POLL,
NULL },
and run this test again? I'm not sure if the value is actually
modified in the UPS. I fear that the HU_FLAG_SEMI_STATIC flag may have
prevented the driver from reading back the value from the UPS.
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin bakd...@gmail.com:
[apc1500]
driver=usbhid-ups
port=auto
ondelay=200
offdelay=1
Yes.
After restarting the driver, and running shutdown.return, the timers
are set to
90 and 200. (the values of ups.delay.shutdown and ups.delay.start)
REBOOT:-1 SHUT:-1 START:-1
REBOOT:-1 SHUT:-1 START:-1
REBOOT:-1 SHUT:89 START:199
REBOOT:-1 SHUT:89 START:199
REBOOT:-1 SHUT:89 START:199
REBOOT:-1 SHUT:85 START:195
REBOOT:-1 SHUT:85 START:195
REBOOT:-1 SHUT:83 START:193
REBOOT:-1 SHUT:83 START:193
Using values of 250 and 1 gives:
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:-1 START:-1
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:-1 START:-1
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:89 START:249
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:89 START:249
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:89 START:249
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:86 START:246
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:86 START:246
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:84 START:244
delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:84 START:244
This looks actually pretty promising. It looks like the UPS sets a
lower limit to the shutdown timer. I would not be surprised if this is
caused by the value that is set in the
UPS.Output.APCShutdownAfterDelay HID path, which is currently set at
90.
Could you try the attached patch on the nut-2.6.0 sources, compile it
again and run the driver again? If all is well, I expect the
'ups.delay.shutdown' to be a modifiable value after that. You could
try if setting it to 20 works. If the above is the case, I expect
there might be a mapping for the 'ups.delay.start' and
'ups.delay.reboot' as well.
If the variable seems to be modifiable, try to run 'shutdown.return'
again while logging as the above.
[...]
Ok, this makes sense now. The Smart-UPS 1000 apparently has some
variations on the 'standard'.
Well, it is not the only UPS (nor vendor) that has. These so called
vendor specific HID paths are allowed by the PDC standard. The problem
is that every vendor can choose what to put in them. So you can't
refer to a standard to find the meaning of them. This is not a problem
if we have full access to the specifications (like Eaton for
instance). But if the vendor is not willing to share them with us
(like APC for instance), we need to reverse engineer them. The latter
is a long, tedious process, which requires lots of help from owners of
these devices.
[...]
Isn't putting the UPS to sleep the desired behaviour here, so that
it wakes up again when power returns?
It should wakeup if the power returns after a power outage. But if the
power happens to return between the moment NUT sees the battery is low
(and initiates the shutdown sequence on the server) and the moment it
sends the shutdown signal to the UPS, it should rather cycle the
outlet to prevent what is known as a power race (see the documentation
for more information). You don't want to see the happening when you're
not around to restart your servers by hand.
[...]
On the CS 500, the shutdown timer is the only one that changes at all. The
reboot and start timers stay at zero (not -1) all the time.
I guess this means that the existing mapping might be wrong. I suspect
that it only has 'shutdown.reboot' and that the other mappings allow
setting the delay values. Note that in the CS 500 these are all vendor
specific HID paths. I'll deal with that, after we fully understand the
operation on the Smart-UPS 1000.
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
Index: drivers/apc-hid.c
===
--- drivers/apc-hid.c (revision 2844)
+++ drivers/apc-hid.c (working copy)
@@ -259,6 +259,7 @@
{ ups.timer.reboot, 0, 0, UPS.PowerSummary.DelayBeforeReboot, NULL, %.0f, HU_FLAG_QUICK_POLL, NULL},
/* used by APC SmartUPS RM */
{ ups.delay.start, ST_FLAG_RW | ST_FLAG_STRING, 10, UPS.Output.DelayBeforeStartup, NULL, DEFAULT_ONDELAY, HU_FLAG_ABSENT, NULL},
+ { ups.delay.shutdown, ST_FLAG_RW | ST_FLAG_STRING, 10, UPS.Output.APCShutdownAfterDelay, NULL, %.0f, HU_FLAG_SEMI_STATIC, NULL },
{ ups.delay.shutdown, ST_FLAG_RW | ST_FLAG_STRING, 10, UPS.Output.DelayBeforeShutdown, NULL, DEFAULT_OFFDELAY, HU_FLAG_ABSENT, NULL},
{ ups.timer.start, 0, 0, UPS.Output.DelayBeforeStartup, NULL, %.0f, HU_FLAG_QUICK_POLL, NULL},
{ ups.timer.shutdown, 0, 0, UPS.Output.DelayBeforeShutdown, NULL, %.0f, HU_FLAG_QUICK_POLL, NULL},
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Cyber Power USB UPS'.
Citeren tubbi...@math.arizona.edu: Debian Server (Lenny) running a Linux 2.6.26-2-686 SMP kernel. NUT version 2.2.2-6.5 (Latest Lenny Stable) [...] Any insights? Upgrade. We no longer support this version of NUT. Since nut-2.2.2 was released, a lot of changes were made to the usbhid-ups driver. Chances are that the problems you're seeing now have been solved already (or not). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Building nut 2.6.0 on OpenBSD 4.8 - compile issue
Citeren Mike. the.li...@mgm51.com: Trying to build nut 2.6.0 on OpenBSD 4.8, I get a compiler error. [...] Making all in drivers gmake[1]: Entering directory `/home/downloads/nut/nut-2.6.0/drivers' gcc -DHAVE_CONFIG_H -I. -I../include-I../include -DSHUT_MODE -g -O2 -Wall -Wsign-compare -MT newmge_shut-usbhid-ups.o -MD -MP -MF .deps/newmge_shut-usbhid-ups.Tpo -c -o newmge_shut-usbhid-ups.o `test -f 'usbhid-ups.c' || echo './'`usbhid-ups.c usbhid-ups.c: In function 'hid_ups_walk': usbhid-ups.c:1231: error: 'EPROTO' undeclared (first use in this function) usbhid-ups.c:1231: error: (Each undeclared identifier is reported only once usbhid-ups.c:1231: error: for each function it appears in.) gmake[1]: *** [newmge_shut-usbhid-ups.o] Error 1 gmake[1]: Leaving directory `/home/downloads/nut/nut-2.6.0/drivers' gmake: *** [all-recursive] Error 1 In the usbhid-ups driver this line is a no-op, so I suggest to comment it out. Question remains why this happens. Either OpenBSD 4.8 is not POSIX compliant or we're not including the right headers. Could you run a grep on your /usr/include directory (or whatever it may be called in OpenBSD) for EPROTO? Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Support of amp; amp; amp; amp; quot; shutdown.returnamp; amp; amp; amp; quot; on a APC Back-UPS CS 500
Citeren Kevin bakd...@gmail.com: On the Smart-UPS 1000, all the instant commands do more or less what you would expect. Looking at the timers using upsc apc1500 I now see that: shutdown. load.off/load.off.delay both set the shutdown timer to 90, shuts down after 90 seconds It looks like this is the minimum time the UPS allows. On almost every other HID PDC UPS we know of, the granularity is much finer than that (usually one to ten seconds). It is quite possible that your UPS was originally designed with a serial interface (possibly even a dumb one) and that the USB interface was added later on. So this may be all the underlying hardware supports. reboot sets the reboot timer to 90, sleeps after 90 seconds Same here. return immediately switches to battery for a moment, sets both shutdown and startup to 90 seconds, sleeps after 90 seconds That is very odd. You could try what happens if you change the 'ondelay' and 'offdelay' values in 'ups.conf'. Set offdelay to 1 second and ondelay to 100/200/400 seconds and run the shutdown.return command again (while monitoring the 'ups.timer.shutdown' and 'ups.timer.start' through upslog or upsc. test.panel and beeper commands also work as expected. So you are right, it does seem to be working on this model. I don't know why I didn't see this when I was testing originally. Also I don't understand why the shutdown.return, which seems to be translated to load.on.delay, load.off.delay is used in preference to the shutdown.reboot command. According to the USB HID PDC specifications, the 'reboot n' command will kill the power immediately and return after 'n' seconds if power is present or will wait until the power returns if it wasn't. We prefer to have a little grace period, so that's why we do the two step approach of setting both the shutdown and (re)start timers. By setting a restart timer longer than the shutdown timer, this effectively allows for a grace period until the UPS switches off. From then it behaves like a reboot command. You need this grace period if you want your system to hibernate instead of shutdown, since the Linux kernel doesn't allow calling hooks just before it powers off the system. Apparently, due to the dreadful granularity of your UPS hardware timers the commands we send load.on.delay 30 load.off.delay 20 are interpreted as setting both to 90 seconds. Worse, since the ups.timer.start elapses before the ups.timer.shutdown, this effectively puts the UPS to sleep. On the CS 500 the load.off switches it off immediately, the load.off delay, shutdown.return and shutdown.stayoff all switch to battery, and set the shutdown timer to 20 seconds and then shuts down after that time. (Never restarts) The beeper commands work, as does the shutdown.stop (sets the shutdown timer to -1) This probably requires some remapping of variables. I'll see if I can find a solution for that. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Support of amp; amp; amp; quot; shutdown.returnamp; amp; amp; quot; on a APC Back-UPS CS 500
Citeren Kevin Myers bakd...@gmail.com: As far as I can tell from your previous message, it works (with nut-2.6.0) for the Smart-UPS 1000, right? No, although it does go into sleep mode if the power is off at the right time, it doesn't cycle the power otherwise so the load will not reboot after the shutdown. I'll do some more testing today. Please also post the output of 'upsc upsname' (see 'man 8 upsc') and 'upscmd -l upsname' (see 'man 8 upscmd') for both devices, so that we can see which commands are detected. It may be a log easier to do the testing with the upscmd 'shutdown.return' (Smart-UPS 1000) and 'shutdown.reboot' (CS-500) while the upsd server is running. During testing, it allows you to run an instance of upslog (see 'man 8 upslog') so that you'll be able to see the 'ups.timer.*' variables counting down. I suspect that the current mapping might be wrong. Also note that the (re)start delay set in the Smart-UPS 1000 is presently set to 180 seconds, so you may have to wait a little longer that expected for the output to be switched on after the power returns. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Support of amp; amp; quot; shutdown.returnamp; amp; quot; on a APC Back-UPS CS 500
Citeren Kevin bakd...@gmail.com: 0.686325 Initiating UPS shutdown 0.686340 upsdrv_shutdown... 0.686365 instcmd(shutdown.return, [NULL]) 0.686382 find_nut_info: unknown info type: shutdown.return This is normal. Some UPS'es (models that have a HID layer around an essential serial interface) support a command that will result in what NUT calls 'shutdown.return', so that's what we try first. A true HID PDC UPS (like the APC models you have) don't, so this command is not found. This is exactly what we expect. 0.686398 instcmd(load.on.delay, 30) 0.686433 Unit = 1001, UnitExp = 0 0.686450 Exponent = 0 0.686464 PhyMax = 0, PhyMin = 0, LogMax = 32767, LogMin = -1 0.690437 Report[set]: (3 bytes) = 28 1e 00 0.690437 Set report succeeded 0.690437 instcmd: SUCCEED In a HID PDC UPS, you need to set both the timer for shutdown and (re)start independently. They start counting down immediately after setting the report, so we set the (re)start timer... 0.690437 instcmd(load.off.delay, 20) 0.690437 Unit = 1001, UnitExp = 0 0.690437 Exponent = 0 0.690437 PhyMax = 0, PhyMin = 0, LogMax = 32767, LogMin = -1 0.695437 Report[set]: (3 bytes) = 12 14 00 0.695437 Set report succeeded 0.695437 instcmd: SUCCEED ...before the stop timer, so that we don't get stuck if the power is lost. In that case, the (re)start timer will have expired and a UPS will not start again. APC CS 500 This shuts down the APC CS 500 after 20 seconds. (and it stays shutdown) This probably means the driver called 'load.off.delay 20', which is the last resort option for the usbhid-ups. It looks like it doesn't have a mapping for 'shutdown.reboot', which the logs you have produced should reveal. APC Smart-UPS 1000 If the power is left on, switches to battery and back online after 2 seconds. Either the HID PDC implementation in this UPS is broken or what you're seeing is 'shutdown.reboot'. The timers are in seconds and with mains present, the UPS should stop 20 seconds after running this command and resume again 10 (30-20) seconds later. If the power is off, goes to sleep after 90 seconds. (and comes back on when the power is connected) This is broken either way. There is nothing we can do about that. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Support of amp; amp; amp; quot; shutdown.returnamp; amp; amp; quot; on a APC Back-UPS CS 500
Citeren Kevin bakd...@gmail.com: It's a shame that I can't seem to get the up to date releases working properly on both of these UPS models, specially after seeing that it can be done, apparently fairly simply, by sending the 0xff86007c code in both cases. As far as I can tell from your previous message, it works (with nut-2.6.0) for the Smart-UPS 1000, right? Anyway, at lease I have now shared the very limited knowledge that I have gained from the exercise with the NUT user community, so maybe, hopefully, someone will be able to benefit from it in the future. They won't, because you have not posted the logs I asked you about. Only those will be able to provide us with the needed information about how to talk to your UPSes. We don't expect you to modify the code, but at least provide us with enough info so that one of the developers can do it. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Support of quot; shutdown.returnquot; on a APC Back-UPS CS 500
Citeren Kevin bakd...@gmail.com: I have been using usb APC units (CS 500 and SmartUPS 1000) with nut for some 6 years. I got this to work after extensive trawling of the net and found a fix involving changing the source and recompiling usbhid-ups (or hidups as it used to be). It's sad that you never submitted these changes back to NUT, so that other people might benefit from them. Now the bad news. Although I am still using the recompiled version of hidups and (64 bit) usbhid-ups, I have stupidly lost the source and my notes. :-( Is it any use to you to have the executables? No. This has been driving me nuts for the last week, as I now have another CS 500 to install, and only a 5 year old version of hidups to do it with! Have you tried the latest version (nut-2.6.0) that was released only a couple of days ago? Chances are that it might just work, since we have seen reports about people running the CS 500 in recent years. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Can't get iDowell to work
Citeren Mick michaelkintz...@gmail.com:
While nut is running, my logs fill up with:
Jan 10 22:50:06 compaq usbhid-ups[5083]: libusb_get_report: No error
Jan 10 22:50:08 compaq usbhid-ups[5083]: libusb_get_report: No error
Jan 10 22:50:10 compaq usbhid-ups[5083]: libusb_get_report: No error
Jan 10 22:50:12 compaq usbhid-ups[5083]: libusb_get_report: No error
regularly at 2 second intervals. Is there a way to tell it to not log
such messages (or log them only once?)
Yes. Make your system not log messages at LOG_DEBUG. Usually you can
configure this in '/etc/syslog.conf'. On a production system, you
should not log messages with LOG_DEBUG since this is reserved for
debugging messages and can be very verbose (risking flooding the logs).
If I add pollonly in ups.conf I get these messages:
Jan 10 23:15:57 compaq upsd[5995]: listening on 127.0.0.1 port 3493
Jan 10 23:15:57 compaq upsd[5995]: Connected to UPS [iDowell]:
usbhid-ups-iDowell
Jan 10 23:15:57 compaq upsd[5995]: allowfrom in upsd.users is no longer used
Jan 10 23:15:57 compaq upsd[5996]: Startup successful
Jan 10 23:15:57 compaq usbhid-ups[5945]: libusb_get_report: could not
claim interface 0: Device or resource busy
Jan 10 23:15:57 compaq usbhid-ups[5945]: Got disconnected by another
driver: Device or resource busy
Jan 10 23:15:59 compaq usbhid-ups[5945]: libusb_get_report: could not
claim interface 0: Device or resource busy
Jan 10 23:15:59 compaq usbhid-ups[5945]: Got disconnected by another
driver: Device or resource busy
... and so on.
Not sure if this is how it should be - but within a few minutes I get:
# upsc iDowell
Error: Data stale
You *must* stop the usbhid-ups driver for a UPS before starting a new
one. The message Got disconnected by another driver: Device or
resource busy is a tell tale sign that you didn't. Before running
'upsdrvctl start', always run 'upsdrvctl stop' first. A crude method
would be to reboot the system, if you can't find the running
usbhid-ups processes. I usually use 'top -u upsd' ('upsd' is the name
of the NUT user on my system) to find any drivers running.
PS. What is the meaning of: battery.capacity: 0.03 ?
This is a mapping problem. The UPS is reporting 100% battery capacity
is available and I mistakenly mapped this to the battery capacity (Ah)
value. I will remove this later on.
Best regards, Arjen
--
Please keep list traffic on the list (off-list replies will be rejected)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Can't get iDowell to work
Citeren Charles Lepple clep...@gmail.com: Technically, HID only needs to be specified on the interface class (device class can be 0), so this descriptor is correct in that regard. If the device is auto detected by Windows and Apple, it is quite possible that this is indeed a HID PDC device. Not sure why it didn't match, though... That's pretty obvious. No subdriver supports this VID:PID combination, so you'll get no match for any of them. What Kjell forgot to mention is that Mick will need to add the 'explore' flag to 'ups.conf' (see 'man 8 usbhid-ups'), so that at least we'll get some debugging output. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Can't get iDowell to work
Citeren Mick michaelkintz...@gmail.com: [ snip ] 0.171361 refresh_report_buffer: expected 4 bytes, but got 8 instead 0.171403 Path: UPS.PowerSummary.DelayBeforeStartup, Type: Feature, ReportID: 0x11, Offset: 0, Size: 24, Value: 0.00 0.171446 Report descriptor retrieved (Reportlen = 412) 0.171461 Found HID device 0.171475 Detected a UPS: iDowell/iBox 0.171490 find_nut_info: unknown info type: load.off.delay 0.171503 find_nut_info: unknown info type: load.on.delay 0.171515 find_nut_info: unknown info type: load.off.delay 0.171542 upsdrv_initinfo... 0.171574 upsdrv_updateinfo... 0.186562 Got 10 HID objects... [snip ...] This keeps going on and on, so I attach the rest as a zipped file to keep the noise down. We probably should have warned you that we only need the first thirty seconds worth of output. Nevertheless, this device indeed speaks HID PDC, so it should be trivial to add this to the usbhid-ups driver. I don't recognize a familiar subset/pattern of commands, so I guess this warrants adding a new subdriver. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] upsd crashes with a broken pipe error
Citeren Zach La Celle lace...@roboticresearch.com: After setting the variable, the only further information I have is this: upsd: free(): invalid pointer: 0x01d20f30 *** Segmentation fault Try again with debug level set to -DDD. This might provide a little more context of where this occurs. Best regards, Arjen PS You're not attempting to run a 32-bit version of the server here, are you? -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Power Walker VI 2000 LCD
Citeren Alexander Todorov atodo...@otb.bg: # upsc powerwalker battery.voltage: 24.60 battery.voltage.nominal: 24.0 beeper.status: enabled device.type: ups driver.name: blazer_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.vendorid: 0665 driver.version: 2.4.3 driver.version.internal: 0.03 input.current.nominal: 9.0 input.frequency: 50.1 input.frequency.nominal: 50 input.voltage: 3.4 input.voltage.fault: 3.9 input.voltage.nominal: 220 output.voltage: 221.0 ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 0 ups.productid: 5161 ups.status: OB ups.type: offline / line interactive ups.vendorid: 0665 I have an additional question though. According to the docs NUT will execute the SHUTDOWNCMD when the battery level becomes low/critical. Is there a way to configure when the battery level is considered low? For example - shut down when battery reaches 50% of its charge. You'll see in the above output that your UPS doesn't report battery charge. The blazer_usb driver can attempt to guestimate the charge remaining (see 'man 8 blazer'), but since the UPS doesn't report the load either, this will not be nearly good enough to base a decision to shutdown on. We really have no reliable means to determine charge remaining if the UPS is not providing us with the necessary measurement values. You'll have to rely on the UPS to warn about a low battery well before it is actually empty to shutdown. If this is not what you want, buy a different UPS that is smart enough to keep track of the charge remaining without the help of a NUT driver. It will invariably also support changing the value at which it decides when the battery is low. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Power Walker VI 2000 LCD
Citeren Alexander Todorov atodo...@otb.bg: You'll see in the above output that your UPS doesn't report battery charge. The blazer_usb driver can attempt to guestimate the charge remaining (see 'man 8 blazer'), but since the UPS doesn't report the load either, this will not be nearly good enough to base a decision to shutdown on. We really have no reliable means to determine charge remaining if the UPS is not providing us with the necessary measurement values. thanks for the pointer. I configured the guesstimate settings described in the man page. Does this mean that when the battery charge reaches the value of default.battery.voltage.low it will shut down? No, see above. This only works if a UPS reports the battery charge itself. The values drivers can calculate are not accurate enough to base a decision on. There is no way to keep track of the battery charge- and discharge current that would be needed to accurately calculate the charge remaining. We also have no idea what is happening to a battery when a driver is not running. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] CyberPower Value 2200E-GP
Citeren David Varley davidavar...@gmail.com: Arjen, now I'm a bit confused. In your script you are saying to shut down nut before issuing the upsdrvctl command to tell the UPS to start a delayed shutdown. Yes. But as shutting down nut causes the usbhid-ups driver to exit, I thought that would prevent the command being sent to the UPS? There are two ways to make a UPS kill it's output: - send a command to a backgrounded driver through upsd to tell it to shutdown (through the web interface or upscmd for instance) - starting the driver with '-k' flag on the command line (this is the method that upsdrvctl shutdown uses, see 'man 8 nutupsdrv') I know that if I just have the upsdrvctl shutdown command without telling the nut service to exit, the UPS shuts down after the 60 second delay. There will be two drivers fighting for control over the same UPS. This will not work at all for serial devices (since the port will be locked by the backgrounded driver). In case of USB connected ones, you might be lucky that the driver started with the '-k' flag will have control over the USB interface long enough to send the shutdown command, but this is not reliable. You should not take your chances here. I can understand adding the delay after giving the shutdown command and before stopping the services, but not the other way around. What am I missing here? You missed reading the docs/suspend-to-disk.txt file, where it is explained how you should set this up. If you want to know the details about this, start reading the remainder of the documents in docs/ before asking. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] CyberPower Value 2200E-GP
Citeren David Varley davidavar...@gmail.com: As far as setting the shutdown command in a script run when hibernating, I did this. I created a script, 48nut, in /etc/pm/sleep.d, as follows: #!/bin/sh # If we are hibernating due to power-fail, initiate a delayed UPS shutdown and then stop the nut services # If we are thawing after this event, start the nut service # DAV 17DEC10 if (test -f /etc/killpower) then case $1 in hibernate|suspend) echo Initiating UPS Powerdown Sequence /sbin/upsdrvctl shutdown echo Stopping nut service service nut stop This won't work. In order to send a poweroff command to the UPS, the drivers must be restarted from scratch. Therefor you must run 'service nut stop' before doing that, otherwise the backgrounded drivers will not have exited. It also is a good idea to put a 'sleep 2' between the two commands, to give the drivers some time to respond to the KILL signal they receive: echo Stopping nut service service nut stop sleep 2 echo Initiating UPS Powerdown Sequence /sbin/upsdrvctl shutdown Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] online zinto usv
Citeren Carsten Burkhardt c.burkha...@b-c-s.de: The help got unfortunately time outs (explore.txt) http://www.networkupstools.org/doc/2.2.0/hid-subdrivers.html Have you an idea for my problems? Looking at the VendorID and ProductID, it is likelt that this device is recognized as a /dev/tttyUSB(0|1...) device. As such you should probably point the blazer_ser or megatec drivers to this port. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] upsdrvctl doesn't seem to start with init.d
Citeren Zachary LaCelle lace...@roboticresearch.com: It's hard to know what works and what doesn't, because when I start the process manually it seems to work fine. Have a look at this bug report and check if this might be the problem: https://bugzilla.redhat.com/show_bug.cgi?id=544121 Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] CyberPower Value 2200E-GP
Citeren David Varley davidavar...@gmail.com: I've just set up a CyberPower Value 2200E-GP on a system running Lucid AMD64, with the current NUT package via apt-get, and it seems to be working fine for me with the usbhid-ups driver, so I guess it can go in the HCL? Probably. We'll just need a little more information like the 'upsc' output for this UPS (to see if we need to add additional mappings). I'm using the system to host several virtual servers under KVM, and to make things simple I set it up to hibernate rather than shutdown, that way all the guest OS don't have to be shutdown, they just carry on happily from where they were after power is restored. To achieve this I timed how long it take to go into hibernation (30-40 seconds), and set the UPS to shutdown after 60 seconds via the driver offdelay setting. I then set: SHUTDOWNCMD /sbin/upsdrvctl shutdown;/usr/sbin/pm-hibernate and under test it works well. I'm don't know if there is a better or right way to do this, obviously the heuristically determined off delay is a bit of a risk, and as the system doesn't actually shut down perhaps there will be other problems with NUT? The /etc/killpower flag isn't deleted, for instance. Remember that the 'upsd' server will latch the FSD (forced shutdown) flag when it has detected an OB LB condition. The only way to reset this, is to restart NUT. Otherwise after resuming, NUT will immediately shutdown again. Many systems will allow you to run scripts when going into hibernation and after resuming. You'll want to stop NUT when hibernating and restart it when resuming (this will take care of the /etc/killpower flag as well). I'd prefer to run the 'upsdrvctl shutdown' command from the hibernation script as well. Also remember that there is a slight risk that if hibernation fails, the UPS will power off anyway. If that worries you, it might be better to stick with a full shutdown of the system. I've attached the output of *usbhid-ups -DDD -a 2200LCD* as there seem to be several errors reported in there. I can see the subdriver doesn't find the serial number, for example, while the pwrstat code supplied by CyberPower does. There are some issues with the usbhid-ups driver in nut-2.4.3. Most of these have been resolved in the development version of NUT. I would be grateful if you could try out this. Most (if not all) of the errors you're seeing now should be fixed. We could add some code to add reading the serial number, but we really need it before claiming the device (which seems to be broken in either your UPS or the version of libusb you're using). Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Setting Battery Runtime Low
Citeren Arnaud Quette aquette@gmail.com: indeed, and a full rewrite is also needed, to support the subdrivers approach as in usbhid-ups. Yes. Although it would be possible to add the lookup (forward and reverse) functions like in usbhid-ups (which would allow for better conversion between IOD - NUT values), it would be much better to start from scratch here. Since I don't have a SNMP capable UPS, I can't really work on it other than the occasional fix for an obvious problem. well, your NMC (in the evolution) is SNMP capable (beside the XML/HTTP channel). Yes and no. It indeed does talk SNMP, but as far as I can see doesn't support changing variables. The only method for changing the 'battery.runtime.low' parameter, is through the HTTP interface. I've not been able to change a single variable through the SNMP interface. depending on your exact card reference and FW version, it will expose a minimum or full set of IETF + MGE MIBS. Currently it reports Network Management Card V6.00 HB (SNMP) Network Management Card/Mosaic 4M 16M/HB (XML) This is the latest firmware I could find for the NMC 66102 (technical level 09). Arjen: if needed, I can also check to send you a more suitable card, but I know that you're already quite busy. It would probably be easier to have access to a device with native SNMP support. I don't need physical access to it, it's enough if I can reach it through the net. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Things seem to be working but upscmd does nothing
Citeren Richard richard-...@rain4us.net: The nut ups daemons seem to be communicating with the UPS but upscmd gives me no joy. Running commands do nothing and produce no output. This is something that needs fixing in 'upscmd'. It erroneously doesn't print the server response after sending off a command, which is very confusing. I already fixed this in the development version a couple of minutes ago. Using the web interface returns an authentication failure and that is the only clue I have. I believe I have everything setup correctly but it's not working. Can someone review this and give me clues as to what I should research next? ups.conf [Hagrid] driver = usbhid-ups port = /dev/apcusb product = Smart-UPS 2200 XL FW:690.19.D USB FW:7.4 serial = JS1005032730 desc = Primary 2200XL with huge battery pack - the big guy Looks good. upsmon.conf MONITOR hag...@localhost 1 nutmon easy master Fine. upsd.users [nutmon] password = easy nutmon master # or upsmon slave If this is all there is in this file, you've missed setting up the permitted instcmds and actions for this user. See 'man 5 upsd.users' for an explanation. Failing to set this up, will default to not allowing instcmds and variable settings at all. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Setting Battery Runtime Low
Citeren Poulton, Stuart W.L. sw...@leicester.ac.uk: rcs-manage-1:/var/log # upsrw phys-eaton [battery.runtime.low] Remaining battery runtime when UPS switches to LB (seconds) Type: UNKNOWN (unrecognized) The definition in the MIB to NUT mapping is lacking a type for this variable. Clients expect it to be either a string or an enumerated value and the driver doesn't report either. This needs to be fixed in the driver, there is no workaround. I suspect from this that it may not be configurable. Maybe, but until this is fixed in the driver it's a driver bug. Note that the snmp-ups driver is currently in dire need of an active developer taking over the maintenance. Since I don't have a SNMP capable UPS, I can't really work on it other than the occasional fix for an obvious problem. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Setting Battery Runtime Low
Citeren Poulton, Stuart W.L. sw...@leicester.ac.uk: I've successfully configured NUT to talk to the SNMP card, however it reports a battery.runtime.low of 1 , not much use, how do I change this value, is it defined by the UPS itself, the SNMP card, or NUT ? This is a configurable value, setting the runtime remaining on battery before the low battery warning is raised. It looks like the driver uses the UPS-MIB::upsConfigLowBattTime OID for this. According to IETF 1628, the units of this value is minutes. So in order to correctly display this in the units NUT uses (seconds) we need to multiply by 60 (similar to the UPS-MIB::upsEstimatedMinutesRemaining that is used for battery.runtime). So I guess what the UPS is trying to tell you, is that the runtime remaining is before it will report battery low, is 60 seconds. Depending on your UPS you might be able to change this value though the 'upsrw' command (see 'man 8 upsrw'). Remember to input this value in minutes for the time being, until we have fixed this. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Belkin Regulator Pro dropping connection and halting
Citeren Arnaud Quette aquette@gmail.com: Thanks for the suggestions, I've added the flush statement as well as some debugging information. As this is a intermittent issue I decided to try overloading the UPS by sending it repeated beeper commands while watching the debug output. What appears to happen is that the UPS returns an unknown ~00R000 response. This means get_belkin_reply() returns -1, causing a datastale state is set when called from do_status(). you should remove the datastale() call since upsd will automatically flag the device as stalled if it has failed to update its data for 15 seconds (default of MAXAGE). Not at all! The upsd server will only declare the *driver* stale if it fails to respond within MAXAGE seconds. However, as long as it keeps answering the PING from the server, it will not be declared stale. This mechanism is something completely different from what happens if the driver calls dstate_datastale(). In that case the driver tells the upsd server that the *UPS* fails to respond. See the chapter on Staleness control in docs/new-drivers.txt. What really needs to be done, is that the driver doesn't treat the ~00R000 reply as an error condition. Apparently the UPS acknowledges the receipt of data, without further response (indicating that 0 bytes follow). The belkin driver doesn't accept this at the moment and requires that a reply follows. This is what needs to be changed. Last but not least, in most drivers, we allow a couple of missed replies before we call dstate_datastale() so that glitches don't lead to automatic reconnects. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Belkin Regulator Pro dropping connection and halting
Citeren John Bayly freebsd.po...@tipstrade.net: Last but not least, in most drivers, we allow a couple of missed replies before we call dstate_datastale() so that glitches don't lead to automatic reconnects. Can you suggest what driver would be a good template to use? Take a look at the upsdrv_updateinfo() function in the 'blazer.c' driver core. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Powercom SXL-1000A-LCD
Citeren ahouse-support supp...@ahouse.mine.nu: I have a traoble whith my ups, - megatec driver can not calculating % of charging and voltage on battery: You UPS doesn't report the battery charge, so that's not unusual. The megatec driver will guesstimate the battery charge based on the battery voltage, but this is very unreliable. [...] # ./nut start Network UPS Tools - UPS driver controller 2.4.1 Network UPS Tools - Megatec protocol driver 1.6 (2.4.1) Megatec protocol UPS detected. Cannot calculate charge percentage for this UPS. !!! [...] # upsc power...@localhost battery.voltage: 2.30 !!! See 'man 8 megatec' for answers how to fix the above two problems. Better yet, change to the 'blazer_ser' driver instead, which uses a better way to determine state of charge (based on a couple of parameters you need to provide). Make sure to read 'man 8 blazer' before returning here for help. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
