similar to: Mustek Powermust 600VA

On Thu, Dec 4, 2008 at 4:51 PM, Arjen de Korte <adkorte-guest at alioth.debian.org> wrote: > Author: adkorte-guest > Date: Thu Dec 4 21:51:28 2008 > New Revision: 1596 > > Log: > Added new richcomm_usb driver based on the lakeview_usb driver (using libusb). Sorry if I wasn't clear - I was advocating *renaming* the lakeview_usb driver to richcomm_usb. Is there another

--- Arjen de Korte <nut+users at de-korte.org> wrote: > > > I also did: > > > > # ./megatec_usb -DDDDD -x vendor=06da -x mfr=OMRON > > /dev/usb/hiddev0 > > Please have a look at 'man 8 megatec_usb' again. > > You probably need to specify the '-x vendorid' and > '-x productid' options > and most likely, the

--- Arjen de Korte <nut+users at de-korte.org> wrote: > > > I also did: > > > > # ./megatec_usb -DDDDD -x vendor=06da -x mfr=OMRON > > /dev/usb/hiddev0 > > Please have a look at 'man 8 megatec_usb' again. > > You probably need to specify the '-x vendorid' and > '-x productid' options > and most likely, the

Hi all, i've read a thread about this UPS from Peter van Valderen. He tried to develop a driver for this specific type of UPS. I've downloaded nut-2.2.2 and tried to apply the patches (lakeview.patch & lakeview.v2.patch) but both resulted in rejected chunks. I've tried to ./configure with type lakeview and then a make, but the make command fails. Does anybody has any

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The

On Mon, Dec 1, 2008 at 7:43 PM, Alexander Gordeev <agordeev-guest at alioth.debian.org> wrote: > Author: agordeev-guest > Date: Tue Dec 2 00:43:04 2008 > New Revision: 1589 > > Log: > * added lakeview_usb driver. Could we possibly rename this driver before it gets into 2.4? As I mentioned in another thread, Lakeview Research is probably not the manufacturer. Note that

Earlier this year, I added a patch to my local NUT tree to additionally print the value of usb_strerror() if usb_clear_halt() failed. (Ignore the commented-out goto.) Since these messages are at the LOG_ERR level, should we add usb_strerror() to all of the calls in nut_usb.c? diff --git a/drivers/nut_usb.c b/drivers/nut_usb.c index 494a1fa..4ca2691 100644 --- a/drivers/nut_usb.c +++

I want to use upsdebugx, upslogx in 'clients/upsclient.c', however this fails with the following error messages (I trimmed the path to the build directory to <path> in order to prevent line wrapping): <path>/clients/upsclient.c:941: undefined reference to `upsdebugx' <path>/clients/upsclient.c:910: undefined reference to `upslogx'

On Dec 4, 2013, at 3:35 PM, Roger Price wrote: > I would like nut to become more loquacious, and to log a much more complete report of its activity. At present nut reports that its components have started operation but does not automatically log their activity when UPS's switch between OB and OL. I believe that this under-reporting of important facts is too minimalist - it would be

Hi, They say one should never argue with people that know more than you, so please bear with me. On 2013/10/24 09:47 PM, hyouko at gmail.com wrote: > The driver is expecting either 'ACK' or no reply at all in case of > success and the command itself echoed back in case of errors. > On the other hand, your UPS replies '(ACK' in case of success and > '(NAK' on

I would like nut to become more loquacious, and to log a much more complete report of its activity. At present nut reports that its components have started operation but does not automatically log their activity when UPS's switch between OB and OL. I believe that this under-reporting of important facts is too minimalist - it would be better for system administrators and for the nut

Hi Johan, The driver is expecting either 'ACK' or no reply at all in case of success and the command itself echoed back in case of errors. On the other hand, your UPS replies '(ACK' in case of success and '(NAK' on failure. So.. when the driver first tries to stop pending shutdowns and you get the 'operation not permitted' error, the driver interprets it as a

On Jul 2, 2013, at 5:16 PM, Kjell Claesson wrote: >> I hope other people can also test this. >> >> Regards >> Alf Hogemark > > Due to some crashes on the disks and lack of time I don't have the git on the > pc now. But maybe some other can commit this. I'd like to ask people to specifically try the bcmxcp branch on GitHub - it includes some changes

Hello, the code below the failing part mentions this flavor of protocol, drivers/blazer_ser.c:463 /* * If a command is invalid, it will be echoed back. * As an exception, Best UPS units will report "ACK" in case of success! */ I prepared a patch, it adds a similar check and also checks (in both occurencies) for blazer_command()<0, the latter

Hi, There seems to be a problem turning of the inverter on a Mecer online 1000VA UPS. OS: Debian Wheezy Nut: Installed via apt - version 2.6.4-2.3 Debug output from driver. root at proxmox1:~# /lib/nut/blazer_usb -DDDDD -a mecer -k Network UPS Tools - Megatec/Q1 protocol USB driver 0.08 (2.6.4) 0.000000 send_to_all: SETINFO driver.parameter.port "auto" 0.000023

On Wed, Dec 3, 2008 at 10:19 PM, <clepple+buildbot at ghz.cc> wrote: > The Buildbot has detected a new failure of FreeBSD-6.2-i686. > Full details are available at: > http://buildbot.ghz.cc/public/nut/FreeBSD-6.2-i686/builds/123 Looks like this was the error: ../../drivers/lakeview_usb.c:58: warning: implicit declaration of function `usb_comm_fail'

----- Doorgestuurd bericht van dkbrig at gmail.com ----- Datum: Thu, 29 Jan 2009 11:16:06 -0600 Van: Danny <dkbrig at gmail.com> Onderwerp: upscode2.c Aan: adkorte-guest at alioth.debian.org Hi, I apologize if you are not the correct person, but I was wanting to submit a bug report for the upscode2.c driver but could not find a way to do that from the NUT website.

Hi, are this UPS supported by any other driver than "richcomm_usb". The device works with richcomm_usb, but only signals online, offline etc. Not voltage, batterylevels etc. Bus 006 Device 009: ID 0925:1234 Lakeview Research Bus 006 Device 009: ID 0925:1234 Lakeview Research Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10