search for: nocomm

Hi, - The device never re-connects to the system, i have to physically remove the USB plug and insert it again for the device to come back. - This does not happen when running the driver from the supplier. (java process) - When i poll every 60s it works for about 3 days, anything lower or higher causes it to disconnect faster - The big log i sent is not the output of the driver? if not how can i

NUT 2.8.01 When I pull the USB cable from the UPS, I get two notifications of the nocomm-timer expired. The first notification is in the proper sequence, the second notification occurs after 'commok' occurs. Seems somehow that upssched-cmd is getting a second nocomm-timer expired delayed. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: <h...

..."onbatt" NOTIFYMSG LOWBATT "lowbatt" NOTIFYMSG FSD "fsd" NOTIFYMSG COMMOK "commok" NOTIFYMSG COMMBAD "commbad" NOTIFYMSG SHUTDOWN "shutdown" NOTIFYMSG REPLBATT "replacebatt" NOTIFYMSG NOCOMM "nocomm" NOTIFYMSG NOPARENT "noparent" NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC NOTIFYFLAG FSD SYSLOG+WALL+EXEC NOTIFYFLAG COMMOK SYSLOG+WALL+EXEC NOTIFYFLAG COMMBAD...

Hi, I have a Liebert UPS which I have connected to a FreeNAS Box. I had all sorts of issues making FreeNAS (FreeBSD based) talk to the UPS over USB. My solution seemed to be to buy a Raspberry Pi then connect it to the UPS (works fine), then make my NAS read the UPS status from the Pi over a TCP/IP connection. Convoluted I know, but it works well...for about a month, then it just loses

...:17 RaspBerry-Pi-3 upssched:: commbad May 27 09:15:17 RaspBerry-Pi-3 nut-monitor[2954]: Network UPS Tools upsmon 2.8.0.1 May 27 09:15:22 RaspBerry-Pi-3 nut-monitor[2953]: UPS [ups at localhost]: connect failed: Connection failure: Connection refused May 27 09:15:22 RaspBerry-Pi-3 nut-monitor[2953]: nocomm May 27 09:15:22 RaspBerry-Pi-3 upsched-cmd.sh:: upsched-cmd.sh running May 27 09:15:22 RaspBerry-Pi-3 upssched:: nocomm May 27 09:15:22 RaspBerry-Pi-3 nut-monitor[2963]: Network UPS Tools upsmon 2.8.0.1 ================================================ NUT configuration 2023-05-27 13:38:31...

..."onbatt" NOTIFYMSG LOWBATT "lowbatt" NOTIFYMSG FSD "fsd" NOTIFYMSG COMMOK "commok" NOTIFYMSG COMMBAD "commbad" NOTIFYMSG SHUTDOWN "shutdown" NOTIFYMSG REPLBATT "replacebatt" NOTIFYMSG NOCOMM "nocomm" NOTIFYMSG NOPARENT "noparent" NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC NOTIFYFLAG FSD SYSLOG+WALL+EXEC NOTIFYFLAG COMMOK SYSLOG+WALL+EXEC NOTIFYFLAG COMMBAD...

...lost? > > My 1. suggestion was option DEADTIME, but seem to be information only. (s. below) DEADTIME expiration is a critical condition if the UPS is on battery when comms are lost, otherwise you are correct, it is only informative. What about a NOTIFYCMD script that checks for COMMBAD or NOCOMM? (passed in $NOTIFYTYPE) You will also need to set the EXEC flag on that event. -- Charles Lepple clepple at gmail

...ebert at 192.x.x.x lost? which occurs in /var/daemon.log if that helps! > The "communications lost" message corresponds to the "COMMBAD" event. The list of events is here: http://www.networkupstools.org/docs/man/upsmon.html#_notify_events There is a similar event, "NOCOMM", which is probably closer to what you are looking for. The `upsmon` daemon checks to see if it has been in the lost-comms state for a certain amount of time (controlled by the "NOCOMMWARNTIME" variable in upsmon.conf; defaults to five minutes), and if so, upsmon triggers the NOCOMM...

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]: libusb_get_string: error sending > control message: Broken pipe > Oct 6 17:30:53 kvm upsd[3533]: Data for UPS [ups] is stale - check driver > Oct 6 17:30:57 kvm upsmon[3548]: Poll UPS [ups at localhost] failed - > Data stale > Oct 6 17:30:57

Huh, must be an OpenDNS issue, it works from my phone. I wonder if I'm running into a similar defect on the PC UPS... I could try resetting the driver every few hours (this, in addition to replugging the cable fixes the issue temporarily), but that does feel like a hack that doesn't fix the root cause. I will try returning the unit and give APC a go. I've previously had good luck

On Mon, 10 Oct 2016, Lane Russell wrote: > 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? I tried from Texas, Miami, Virginia, and New York VPSes. Works fine. Maybe try again, or check your local DNS? > I was able to get it to run unattended with this hack: >

> On Oct 10, 2016, at 2:12 PM, Stuart D. Gathman <stuart at gathman.org> wrote: > > On Mon, 10 Oct 2016, Lane Russell wrote: > >> 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? > > I tried from Texas, Miami, Virginia, and New York VPSes. Works fine. >

> On Oct 6, 2016, at 7:26 PM, Lane Russell <lanerussell028 at gmail.com> wrote: > > Ubuntu Server 16.04.1 LTS > NUT 2.7.2-4ubuntu1 > Apologies if you mentioned this already, but which kernel are you running? Looking back over the recent USB problems, we saw a lot of problems with the 3.16 kernel, for instance. -------------- next part -------------- An HTML attachment was

On 10/10/2016 11:12 AM, Stuart D. Gathman wrote: > On Mon, 10 Oct 2016, Lane Russell wrote: > >> 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? > > I tried from Texas, Miami, Virginia, and New York VPSes. Works fine. > Maybe try again, or check your local DNS? >

On Oct 12, 2016, at 9:07 AM, Lane Russell wrote: > > Apologies, I did mean upsmon.conf. ups.conf "pollinterval" is not called out, so I assume it's using the default of 2s. "pollfreq" and "pollfreqalert" are both set to 10s in upsmon.conf at the moment. "deadtime" is set to 30s. No problem, the names are a bit confusing. > I've attached

No, just a few extra hours in the day :) This is a tougher problem. In the mean time, can you make sure the "Got disconnected by another driver " is not really caused by an extra instance of the NUT driver? (Could be kernel or other user space activity) - Charles > On Oct 21, 2016, at 11:37 AM, Lane Russell <lanerussell028 at gmail.com> wrote: > > Do you need any more

On Oct 24, 2016, at 10:38 AM, Lane Russell <lanerussell028 at gmail.com> wrote: > > How could I check if another instance is causing me issues? This is a running on a KVM host server, so there's very little activity on the server itself. There should only be one usbhid-ups process running at any given time. Also, from your description, this does not sound likely, but was there a

There's no GUI here; NUT Is running on a headless server. There is only one usbhid-ups process running: nut 13710 0.0 0.0 17320 344 ? Ss Oct21 0:18 /lib/nut/usbhid-ups -a ups On Mon, Oct 24, 2016 at 6:11 PM, Charles Lepple <clepple at gmail.com> wrote: > On Oct 24, 2016, at 10:38 AM, Lane Russell <lanerussell028 at gmail.com> > wrote: > > >

I finally got the PPA updated: https://launchpad.net/~clepple/+archive/ubuntu/nut The latest version there was built with libusb-1.0 instead of libusb-0.1. I still get the occasional issue with the Tripp Lite 3016 device with this code, but it seems to be less frequent. I will need to swap around some equipment to be able to test against a CyberPower UPS (mine isn't an LCD model, though).

How could I check if another instance is causing me issues? This is a running on a KVM host server, so there's very little activity on the server itself. On Sat, Oct 22, 2016 at 1:16 PM, Charles Lepple <clepple at gmail.com> wrote: > No, just a few extra hours in the day :) > > This is a tougher problem. > > In the mean time, can you make sure the "Got disconnected