search for: datastale

In repsonse to the problem with "Belkin Regulator Pro dropping connection and halting" in ups-users, I've submitted the patch to help with the issue: https://alioth.debian.org/tracker/index.php?func=detail&aid=312877&group_id=30602&atid=411544 I didn't have any reports of people's eyes bleeding from reading the code, and it's been doing the job quite

...and 2.6.0. While I can see some improvements, bcmxcp_usb 2.6.0 does not appear to handle a USB cable unplug-plug correctly. Does anyone know if this has been fixed in subsequent releases? Here are the details. When the USB cable between my server and my PW5115 UPS is removed, bcmxcp_usb reports DATASTALE (as it should) and continues to respond to PING (as it should). When the USB cable is reattached, bcmxcp_usb continues to report DATASTALE in response to DUMPALL even though lsusb indicates that the PW5115 is indeed connected and DATAOK is never reported in response to DUMPALL. If I restart the b...

...lost. - upsc sms always returns "Error: Data stale" 3096.067419 smsBR_RecAnswer: Started 3098.069531 smsBR_RecAnswer: Exiting by timeout (2 seconds) 3098.069592 Communications with UPS lost: upsdrv_updateinfo: UPS at port /dev/ttyUSB0 is returning by timeout... 3098.069617 send_to_all: DATASTALE 3098.069699 send_to_one: PONG 3101.070466 smsBR_RecAnswer: Started 3103.072605 smsBR_RecAnswer: Exiting by timeout (2 seconds) 3103.072686 Communications with UPS lost: upsdrv_updateinfo: UPS at port /dev/ttyUSB0 is returning by timeout... 3106.073475 smsBR_RecAnswer: Started 3108.075605 smsBR_RecA...

Hello again! Sorry for not being able to test this before. Ulisses, please apply the patch to fix typo in my e-mail address. I've compiled it against nut-2.6.5 about 10 hours ago. It was everything fine until now. I'm seeing CHRG but the ups led wasn't blinking at all. Vendor software was strangely showing charging also. I am assuming this is expected behavior. I've set the

...RT1U" 10.721708 send_cmd(msg_len=2, type='S') 10.722544 send_cmd: sending 3a 53 ac 0d 00 00 00 00 '.S......' 10.824514 send_cmd: received 53 01 04 00 00 64 00 0d 'S....d..' (OK) 10.824815 Unknown value for s[1]: 0x01 10.824999 send_to_all: DATASTALE 10.825812 send_cmd(msg_len=2, type='L') 10.826909 send_cmd: sending 3a 4c b3 0d 00 00 00 00 '.L......' 10.928616 send_cmd: received 4c 00 00 00 07 58 58 0d 'L....XX.' (OK) 10.928996 send_cmd(msg_len=2, type='D') 10.929205 send_cmd: send...

[...] > I think this output doesn't help very much. This is very helpful. The problem is not in the connection to the driver, upd->data_ok switches between 0 and 1. Only the driver can change this value by repetitively switching between DATASTALE and DATAOK. There is nothing upsd can do about this, this is a driver problem. This is consistent with the observation that all people reporting similar problems are using the newhidups (or usbhid-ups) drivers. I can't reproduce this with the 'safenet' driver either (different UPS thoug...

I finally nailed down the problem with upsd declaring data stale when resuming from suspend. The problem is two fold (not surprisingly): 1) The dstate_dataok() and dstate_datastale() routines in 'drivers/dstate.c' will only 'broadcast' *changes* in the driver state. Since the driver has no notion of time, it won't notice at all that it was suspended. Therefor, after resuming it is business as usual for the driver and it won't broadcast any state change...

[As posted as Ubuntu Question #184284 on Launchpad] Hi, I try to set up nut (2.4.3) on my Lucid (10.04.3 LTS) to make use of my old but very trusty UPS (Best Power Fortress 660 LI). Yes, this UPS is old (about 16 years), but with its third battery pack last week it is as good as new. It runs perfectly well with Windows XP, Vista and even Windows 7. But not so with Ubuntu and nut. After

Hi All, I've finally found solutions for my previous problems. But since this includes changes in the shared files, I'd like to discuss them here. 1. Driver restart problem. When I start the driver for the first time, everything is ok. But when I want to restart it, problems begin. The driver fails to read Report descriptor for the second time (libusb_open is used to open the device).

...get_answer(33) 250.950973 get_answer: exiting (len=0) 251.962220 entering get_answer(33) 251.962302 get_answer: (1 bytes) => fb 251.962334 get_answer: wrong header 252.982281 entering get_answer(33) 253.833035 get_answer: exiting (len=0) 253.833070 send_to_all: DATASTALE 253.833091 Short read from UPS 253.833141 Signal 2: exiting 253.833266 CLOSING # -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF

..._to_all: SETFLAGS ups.id RW STRING > > 9.990984 send_to_all: SETAUX ups.id 5 > > 9.991202 Unit ID: 0 > > 9.991406 send_to_all: SETINFO input.voltage.nominal "120" > > ^ 120V might just be the default. > > > That last little bit between DATASTALE and DATAOK seems to loop on through > > infinity. Has anyone actually made this model work with nut? I have dug up > > some other very old threads that all seem to dead end without a solution. > > Don't think so, but I think we can make this work with some code > changes....