similar to: Keeps losing connection with UPS (local usb connection)

I?m setting up a new system and installed a new UPS with nut. System Specifics: OS: Debian 3.16.36 Nut version: 2.7.2 Install method: apt-get Device: TRIPPLITE SMART1300LCDT using usbhid-ups driver Problem: The output from upsc has a few incorrect values. They appear to be a matter of scale. root at server:/etc/nut# upsc tripplite at localhost Init SSL without certificate database

On 08/05/2016 03:03 PM, Marco Walther wrote: > On 08/05/2016 01:36 PM, Stuart D. Gathman wrote: >> On Fri, 5 Aug 2016, Marco Walther wrote: >> >>> On 08/03/2016 05:25 AM, Stuart Gathman wrote: >>>> I've made some progress getting this Tripplite to work: >>>> http://gathman.org/2016/07/30/Standard_Schmandard/ >>>> >>>>

I tried viewing your link, but it returns a 404 error. It also doesn't seem to have a valid certificate. Could you send the correct link please? On Thu, Oct 6, 2016 at 9:14 PM, Stuart Gathman <stuart at gathman.org> wrote: > On 10/06/2016 07:26 PM, Lane Russell wrote: > > ?? > Syslog after server loses sight of UPS: > Oct 6 17:29:01 kvm usbhid-ups[3529]:

I've made some progress getting this Tripplite to work: http://gathman.org/2016/07/30/Standard_Schmandard/ Basically, plug it into a USB hub that actually implements USB2.0, then power cycle the port when it hangs. It does seem to be a hardware problem with the USB controller. On 05/24/2016 09:06 AM, Charles Lepple wrote: > On May 22, 2016, at 10:18 AM, Stuart Gathman wrote: >> I

Hi can anyone please help. I have two linux servers both with static IPs not using NAT. My slave can't connect to my host. Whatever I try. I have the same setup also on my LAN with two other machines and they talk to each other and work great. But my two machines with their own static IPs don't want to play. I've used the same settings for these as I have on my LAN, with a master

Hi Charles, Thank you so much for getting back to me. I should have given you a bit of background in my last message but I'm actually doing this for my grandmother's benefit! She has Dementia and lives on her own so we want to be notified if she has a power cut... I'd hate to think she might be stumbling around in the dark (which has happened before)! In terms of stopping the older

I noticed that many configuration options (configure.txt) have environment variable overrides. However, an important one does not. In the configuration.txt file, there is one section: Directories used by NUT at run-time ----------------------------------- --with-pidpath=PATH Changes the directory where pid files are stored. By default this is /var/run. Certain programs like upsmon will

Or just set up sane firewall rules to allow the two to talk, but block external traffic. I have run this way for years - all add'rs ar IANA in a subnet block, and just that block is open locally, and all other external IP's severely restricted, and NUT works great . . . - Tim On September 12, 2016 11:47:28 AM CDT, "Stuart D. Gathman" <stuart at gathman.org> wrote: >On

Hello, sorry for disturbing the list but i am just an "amateur" and have problem to configure the nut network For the config I have one NUT server and want ot have two clients The client on the NUT server is running well but the client on the network is not able to connect to the server The NUT server is an ubuntu 18.04 machine. If I run the nut monitor on the server, the monitor

On 2019-02-16 12:41 p.m., Stuart D. Gathman wrote: > On Sat, 16 Feb 2019, James wrote: > >> These changed: >> battery.runtime: >> ups.load: >> >> Is the battery dead again? >> Do I need a new UPS? > > Compare the upsc output with the screen/led display on the UPS.  If they > are in agreement, then there is no problem with NUT.  Your issue is

The battery was replaced in December and the output from upsc was: $ upsc desktop_ups battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 20 battery.mfr.date: CPS battery.runtime: 1020 battery.runtime.low: 300 battery.type: PbAcid battery.voltage: 13.5 battery.voltage.nominal: 12 device.mfr: CPS device.model: UPS CP850AVRLCD device.type: ups driver.name: usbhid-ups

Our server has 2 UPS on 2 PSUs. At 8am, someone unplugged one UPS. At 8:10, they plugged it back in, but turned off the load - presumably to stop the beeping. So the system is still up on 1 PSU, and can talk to both UPS. Can't I turn on the load via USB? upsc output for the UPS that is off: battery.charge: 100 battery.charge.low: 15 battery.charge.warning: 50 battery.date: 2001/09/25

Thanks, Charles. I pulled your change and it fixed my segmentation fault. I discovered the following code at line 571 in usbhid-ups.c. This is part of the "checking for alternatives" code: if (!strcasecmp(cmdname, "shutdown.return")) { int ret; /* Ensure "ups.start.auto" is set to "yes", if supported */ if

On 5/28/19 3:39 PM, Julian H. Stacey wrote: > grumpy at mailfence.com wrote: >> a friend gave me an old apc smart-ups 1250 >> it has a rs232 interface but i have no pc with a rs232 port >> i attempted to use a rs232 to usb adapter but the ups goes nuts >> i connected the ups to batteries and verified it was working properly >> when i plug the usb cable into the pc

On Mon, 3 Apr 2017, Gene Heskett wrote: >>> Nut, IIRC, can do a periodic battery test by putting it offline, >>> using the battery, for a predetermined length of time, weekly, >>> monthly etc, >> >> We definitely don't want that in this instance either! > > Why not? If the battery has a holdup time of 5 minutes when its fresh, Because in this

On Mon, 3 Apr 2017, Gene Heskett wrote: >> > Nut, IIRC, can do a periodic battery test by putting it offline, using > the battery, for a predetermined length of time, weekly, monthly etc, We definitely don't want that in this instance either! (Unless it is a dual PS server.) We want the ALARM that the nut driver is generating, and upsd is passing on - to be acted on in some

Hi, I cant get it working. Here is my terminal output: root at debian-jessie-final:~# lsusb -d 051d:0002 Bus 001 Device 010: ID 051d:0002 American Power Conversion Uninterruptible Power Supply root at debian-jessie-final:~# ls -l /dev/bus/usb/001/010 crw-rw-r-- 1 root nut 189, 9 Mai 6 15:35 /dev/bus/usb/001/010 root at debian-jessie-final:~# sudo upsdrvctl start Network UPS Tools - UPS driver

The if() statement always evaluated to true. Detected by "cppcheck", not tested on real hardware. Signed-off-by: Thomas Jarosch <thomas.jarosch at intra2net.com> --- drivers/rhino.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/rhino.c b/drivers/rhino.c index ca66169..e478bcb 100644 --- a/drivers/rhino.c +++ b/drivers/rhino.c @@ -187,7 +187,7

On Mon, 6 May 2019, Gareth Davies wrote: > Just to say, I stopped the driver and started it again and the errors went > away! However, I turned off power to the UPS but I wasn’t receiving any > e-mails :( also when I rebooted the RPi the driver/service didn’t start back > up automatically...  > > I wonder if you have any thoughts on the above? Those are issues with

On Tuesday 07 May 2019 09:49:47 am Charles Lepple wrote: > On May 7, 2019, at 9:09 AM, Gene Heskett wrote: > > On Tuesday 07 May 2019 08:38:44 am Charles Lepple wrote: > >> On May 7, 2019, at 5:06 AM, Gene Heskett wrote: > >>> New testing install(stretch) > >>> pulled in nut stuff from repo. > >>> copied old wheezy configs to /etc/nut,