search for: sdgathman

...ogle, but hal likes to grab the USB ups before nut can get it. There are a number of klugey workarounds, like turn off port power until ready to start nut (so that hal doesn't see the UPS). Or killall hal-addon-hid-ups before starting nut. Here is one of recipes I googled: https://github.com/sdgathman/trippfix/blob/master/halpolicy.fdi It doesn't work - hal still loads the addon - preventing nut upsdrvctl from succeeding. I'm thinking the killall is the least dirty workaround, but what is the right way to tell hal not to mess with the UPS (or any UPS for that matter).

On 11/13/2016 10:08 AM, Charles Lepple wrote: >> Here is one of recipes I googled: >> https://github.com/sdgathman/trippfix/blob/master/halpolicy.fdi > What if you convert the USB ID numbers to decimal? > > <match key="@info.parent:usb.vendor_id" int="2748"> > <match key="@info.parent:usb.product_id" int="12310"> > > Ref: ht...

...> > > This particular new unit came with its own USB cable, and this unit is > > plugged into a relatively old server. The motherboard is about ten > > years old. > > > I also had this problem with this unit. My hacky solution solution is > here: https://github.com/sdgathman/trippfix > > I'm convinced that the USB interface on these units is braindead - > despite their other excellent qualities (excellent handling of > outages). Many other people have the same problem with this unit, > including Windows users with the supplied proprietary monitoring...

Charles Lepple writes: > On Sun, Apr 2, 2017 at 2:59 AM, Sam Varshavchik <mrsam at courier-mta.com> > wrote: > > Having trouble configuring nut 2.7.4 on Fedora 25, with a new Tripp Lite > > UPS. > > > > I'm running XFCE, and XFCE's Power Manager sees the UPS just fine. lsusb > > gives: > > > > Bus 006 Device 002: ID 09ae:3016 Tripp

Installed a new Tripplite Smart1500LCD on a CentOS 7 host using the usb connector. Nut does connect: $upsc ups battery.charge: 100 battery.runtime: 1407 battery.type: PbAC ... But after a half hour or so the connection is lost. Restarting nut re-establishes the connection. Any idea what might be causing the dissconnection?

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

On 9/23/2020 1:09 PM, Stuart D. Gathman wrote: > I solved this problem a few years back. > > https://github.com/sdgathman/trippfix > > The short answer is USB is broken on the model (but the power management > is excellent, handling switchover to generator power without a hitch). > > The workaround is to do a usb port power off when the Tripplite USB > hangs.  But hubs that actually implement this ma...

...PS). Or > killall hal-addon-hid-ups before starting nut. Minor nit, but for anyone else using an exact match search interface (like packages.ubuntu.com), note that there is a "d" after "hal": hald-addon-hid-ups > Here is one of recipes I googled: > https://github.com/sdgathman/trippfix/blob/master/halpolicy.fdi What if you convert the USB ID numbers to decimal? <match key="@info.parent:usb.vendor_id" int="2748"> <match key="@info.parent:usb.product_id" int="12310"> Ref: https://ubuntuforums.org/show...

.../networkupstools/nut/pull/122 > > This particular new unit came with its own USB cable, and this unit is > plugged into a relatively old server. The motherboard is about ten > years old. > I also had this problem with this unit. My hacky solution solution is here: https://github.com/sdgathman/trippfix I'm convinced that the USB interface on these units is braindead - despite their other excellent qualities (excellent handling of outages). Many other people have the same problem with this unit, including Windows users with the supplied proprietary monitoring software, so I think it...

I solved this problem a few years back. https://github.com/sdgathman/trippfix The short answer is USB is broken on the model (but the power management is excellent, handling switchover to generator power without a hitch). The workaround is to do a usb port power off when the Tripplite USB hangs. But hubs that actually implement this mandatory feature (must at lea...

Hello fellow victim of Tripplite braindead USB! There is a solution! My blog on diagnosing the problem: https://gathman.org/2016/07/30/Standard_Schmandard/ My blog on packaging the solution: https://gathman.org/2016/11/09/Packaging/ Solution on github: https://github.com/sdgathman/trippfix Sadly, you will have to buy a USB standard conforming powered hub to make the Tripplite work. These are suprisingly hard to find, but the solution includes a list of known working hubs. I use a small visibly powered USB device like a light or fan to test whether the hub really works....

OS: Debian 3.16.36 Nut version: 2.7.4 from the ?stretch? distribution (this was to solve another problem ? which it did) Install method: apt-get Device: TRIPPLITE SMART1300LCDT using usbhid-ups driver Problem: I keep getting the message UPS tripplite at localhost is unavailable If I do? service nut-server stop service nut-server start Then everything is fine again for a while.