similar to: Connecting to Tripp-Lite SNMPWEBCARD

I missed that snmp-ups set pollfreq to 30 by default. I'd hope that it would set deadtime to an appropriate value as well than, no? Is there a way to query what the settings are or what the defaults are? I'm going to set POLLFREQ=30 and DEADTIME = 90 and see if that has any effect. I'll check for the logs. And if that doesn't get my anywhere I'll look at trying to simulate

[please use Reply-All to keep the list CC'd, thanks] On Mar 30, 2015, at 11:04 PM, Jason Gould <jgould at cddiagnostics.com> wrote: > Thanks. I should also mention the freenas server is setup with an lacp lagg. > > I will also mention that even when not setting pollfreq (leave as default) the issue still occurs. > It looks like the default for pollfreq is actually 30 on

Just started using NUT and having a problem. I'm not sure if it is even NUT that is causing the issue. I'm running the latest FreeNAS 9.3 release. Network UPS Tools upsmon 2.7.2. The UPS is a Tripplite SU6000RT4UHVPM with the SNMPwebcard installed. I'm trying to use the SNMPwebcard, not USB or Serial. I've updated the SNMPwebcard to the latest firmware version (see below). In

Hey, was wondering if I could get a quick sanity check. We have a SmartUPS 1500 RM2U which we have connected to a box via USB. It seems like every 40-45 seconds it becomes disconnected and reconnected. Though this only happens when we have NUT enabled, otherwise it's fine. When it is disconnecting and reconnecting running lsusb doesn't show it disconnecting. After having it sit like that

Thanks. As mentioned, deadtime can't be set for snmp-ups. You see this in the logs. Mar 31 09:08:30 freenas notifier: Fatal error: 'DEADTIME' is not a valid variable name for this driver. Mar 31 09:08:30 freenas notifier: Look in the man page or call this driver with -h for a list of valid variable names and flags. While looking at /var/log/messages I also see this when starting

I am experiencing the same kind of disconnects, stale data on Eaton brand UPS (Nova AVR). It keeps doing it probably due to Windows to detect it as a new hardware, until Eaton software is installed. With Eaton Linux IPP http://pqsoftware.eaton.com/explore/eng/ipp/default.htm?lang=en this does not happen. Think what? It disables it somehow. But as soon as you remove this proprietary driver, its

All, We think we found something that is causing the problem but as of right now we are unsure as to why it might be causing the issue. Recently I had to restart testing this to figure it out and for some odd reason I wasn't able to reproduce it with any system but our own custom system. I then noticed that in ups.conf I did not set the pollinterval, we normally set it to 15, so I set it to

Some of my messages never went through since I hit a message size limit. I'm resending them in the hopes they are under the limit. Charles, The lsusb command did not trigger a disconnect. The output of that command is below. I ran "usbhid-ups -a upsunit -DDD &> output.log" and I have attached the /var/log/messages and output.log to this email. Before running this test

On Mar 31, 2015, at 9:07 AM, Jason Gould <jgould at cddiagnostics.com> wrote: > I missed that snmp-ups set pollfreq to 30 by default. I?d hope that it would set deadtime to an appropriate value as well than, no? Is there a way to query what the settings are or what the defaults are? There is a TODO comment in snmp-ups that mentions doing something similar to usbhid-ups: just poll the

Charles, We did notice that there were two categories. Is there a way if we could determine if it is colliding? We do have a USB analyzer so I'll see if that can be used to determine if the UPS is disconnecting due to inactivity on the bus. Thanks! Shade On Tue, Nov 18, 2014 at 8:40 PM, Charles Lepple <clepple at gmail.com> wrote: > On Nov 18, 2014, at 6:28 PM, Shade Alabsa

On Nov 18, 2014, at 6:28 PM, Shade Alabsa <shade34321 at gmail.com> wrote: > I then noticed that in ups.conf I did not set the pollinterval, we normally set it to 15, so I set it to test on a RHEL 6.6 machine which caused this issue to happen again. On our own custom system we took the poll interval out and prelim testing doesn't showing the repeated disconnects/reconnects. I started

On Sep 19, 2014, at 7:48 PM, Shade Alabsa <shade34321 at gmail.com> wrote: > So I was wondering does NUT do anything which would cause the USB to disconnect? Not intentionally, no. The reconnection code is meant to clean up after these disconnection events, but it is something that isn't expected all that frequently. > I didn't think so and I couldn't find anything yet

Charles, So I installed a minimal CentOS 6.5 installation on the Fedora box this morning and I got the same issue. Below are the kernel versions used. CentOS 6.5 Minimal - [root at nemo tmp]# uname -a Linux nemo 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [root at nemo tmp]# rpm -qa | grep nut nut-2.6.5-2.el6.x86_64 nut-client-2.6.5-2.el6.x86_64

Re: "Does it work well with NUT?" Assuming it is the SU5000RT4UHV, the similar units I've tried seemed to work fine. For reference, the SU5000RT4UHV should be a 4004 USB protocol. ________________________________ From: David Zomaya Sent: Wednesday, March 25, 2020 5:21 PM To: Lee Damon; nut-upsuser Mailing List Subject: Re: [EXTERNAL] [Nut-upsuser] thoughts on tripp lite Smart

On Sep 29, 2014, at 12:50 PM, Shade Alabsa <shade34321 at gmail.com> wrote: > The lsusb command did not trigger a disconnect. The output of that > command is below. If you run lsusb several times, does it still work? The exact output of lsusb isn't as important as whether anything gets logged by the kernel. Running lsusb shouldn't cause any extra kernel messages such as

Charles, > If you run lsusb several times, does it still work? The exact output of lsusb isn't as important as whether anything gets logged by the kernel. Running lsusb shouldn't cause any extra kernel messages such as the disconnection/reconnection messages shown here: Running lsusb seveeral times works just fine and no disconnects are observed. > This

I'm obviously biased but I like Tripp Lite stuff. I try to pitch in and help with Network UPS Tools issues related to Tripp Lite when I can too (albeit the developers and users on this list are usually more helpful than me). Just to confirm, it sounds like you are looking at the SU5000RT4UHV, correct?

Soon as I get back to that computer I will let you know which kernel version. Both were just recently installed, Fedora was installed specifically for this actually, though updates have been applied. I've tried it with other USB ports already across 5 different machines. I've also swapped out the USB cable for another one that I knew worked fine. I'll see what I can do about

On Sep 22, 2014, at 11:14 AM, Shade Alabsa <shade34321 at gmail.com> wrote: > These machines are exact replicas of each other and are fairly old and have a Core 2 Duo E8400 CPU in them. Is there anything else you need or anything I can do to help fix this? Thanks! Also, Barry Skrypnyk mentioned that Fedora was one of the Linux distributions that Tripp Lite claims to support. I recommend

Charles, > What is the new behavior? The CentOS minimal install had different print statements and a broadcast message whenever the UPS was disconnected. The broadcast isn't really important. Below are the differences I pasted though I'm not sure if they are important, I just noticed they were different. Particularly the bolded parts which I think you alluded to in your email about