similar to: HAL and UPSs (was: Small feature request for 0.5.9)

Charles, It looks like the buildbot no longer builds (if it ever did, I don remember) the HAL addons, even if the requirements are met: configure:9680: checking for libhal version via pkg-config (0.5.8 minimum required) configure:9690: result: 0.5.11 found configure:9694: checking for libhal cflags via pkg-config configure:9703: result: -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal

Hi fellows, I'm really pleased to announce that a first stage of NUT and HAL [1] integration has been reached: NUT drivers (in fact, only newhidups, tripplite_usb and bcmxcp_usb for the moment) can feed HAL data. It's a "quick and dirty" hack, as a proof of concept, and there is still lots of things to be done, both on NUT and HAL sides. But it's a good base, and very

Hi David and fellows, I'm reviving this important thread about a common power management. To sum up, the first aim is to allow a better user experience on Linux by bridging NUT with Linux HAL, and Gnome Power Management / any PM GUI. But it also initiate a bigger investigation about how to integrate NUT support for UPSs into the native OS Power Management infrastructure for all supported

Hello there, w/ my CentOS6 (up-to-date), running GNOME, I'm struggling with HAL and mount options for my USB storage devices. According to what I'm reading from: http://www.linuxfromscratch.org/blfs/view/svn/general/hal.html My old policies in /etc/hal/fdi/policy/ are ignored (and this is true!). Apparently I should edit my custom mount options through gconf-editor (in

Hi, is there anybody understanding HAL? I use CentOS 4 (RHEL 4) I need set specific mount options for USB flash disk. I found I can do it in /usr/share/hal/fdi/95userpolicy/storage-policy.fdi <?xml version="1.0" encoding="ISO-8859-1"?><!-- -*- SGML -*- --> <deviceinfo version="0.2"> <device> <match key="volume.fstype"

I've tried several recipes found with google, 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

On Wed, Mar 5, 2008 at 4:44 PM, Arjen de Korte <adkorte-guest at alioth.debian.org> wrote: > Author: adkorte-guest > Date: Wed Mar 5 21:44:41 2008 > New Revision: 1358 > > Log: > - fix HAL support [Alioth Bug #304156] (backport from r1294) > - only include target specific CFLAGS and LDFLAGS only if target is actually used (backport from r1296 and r1297) > - add

2010/12/22 Arjen de Korte <adkorte-guest at alioth.debian.org> > Author: adkorte-guest > Date: Wed Dec 22 20:31:42 2010 > New Revision: 2777 > URL: http://trac.networkupstools.org/projects/nut/changeset/2777 > > Log: > Don't version generated files > > Deleted: > trunk/scripts/hal/ups-nut-device.fdi.in > trunk/scripts/hotplug/libhid.usermap >

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"

Citeren Arjen de Korte <adkorte-guest at alioth.debian.org>: > Author: adkorte-guest > Date: Thu Jan 15 20:02:22 2009 > New Revision: 1734 > > Log: > Freshly generated USB helper files > > Modified: > trunk/scripts/hal/ups-nut-device.fdi.in > trunk/scripts/hotplug/libhid.usermap > trunk/scripts/udev/nut-usbups.rules.in Questions is, should we try

I bought a new CyberPower CP850AVRLCD ups, connected it to a usb port and I'm trying to use it with hal. I installed [root at phoenix ~]# rpm -q nut nut-client nut-2.2.0-6.1.fc8 nut-client-2.2.0-6.1.fc8 lsusb sees it: [root at phoenix docs]# lsusb Bus 001 Device 001: ID 0000:0000 Bus 005 Device 002: ID 0c45:1050 Microdia Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000

On Nov 11, 2016, at 1:01 PM, Stuart Gathman wrote: > > I've tried several recipes found with google, 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. Minor nit, but for anyone

I forgot to cc you guys on the future evolution of the HAL support (it's replacement in fact, called DeviceKit) A mailing list dedicated to DeviceKit is under creation. If some of you are interested in, just answer back. -- Arnaud ---------- Forwarded message ---------- From: Arnaud Quette <aquette.dev at gmail.com> Date: 2008/6/24 Subject: Re: DeviceKit-power patches To: Richard

[was: svn commit r915 - in trunk: . drivers] Hi Kjell, sorry, I'm still much late in emptying my mail stack... 2007/5/25, Kjell Claesson <kjell.claesson at epost.tidanet.se>: > Den Friday 25 May 2007 08.52.20 skrev Arnaud Quette: > > > > I would be interested in some more info: > > - lshal -u <your device's UDI> > > the UDI can be obtained for ex.

some notes: - for this kind of discussion, please cc upsdev list (I've added it), - I've fwded the full thread to upsdev, - this subject is part of what I call NUT-NG (next gen.), aka nut 3.0... - I'll study in depth the thread this week end, and complete with my thoughts, - thanks to Stan to have put us all in touch Arnaud 2006/3/10, Stanislav Brabec <sbrabec@suse.cz>: >

Adel Gadllah (1): Re-enable TapButtons and CornerButtons to work by default. Christian Schmitt (1): Add support for Apple touchpads to the fdi file Christoph Brill (6): Add .fdi file from gentoo (also used by pld) Fix "make distcheck" Use config.h if available Update man page to contain a paragraph about fdi files Add a note on how to pass

Hi Guys, I'd like to submit a patch to enable NUT to communicate with APC 5G UPSs. The current usbhid-ups driver recognises APC UPSs by the Vendor ID and Product ID of 0x051D and 0x0002. This needs to be amended with the new Product ID of 0x0003. (See attached file: apc-hid.patch) Secondly, when Nut polls the UPS via the interrupt channel, these will time out, resulting in frequent lost

I have been happily using NUT to monitor a couple of Eaton UPS. These are independent UPSs, each driving one "leg" of the power in our data center. In this scenario, I've told my clients they need to have one UPS working and to shutdown when the last UPS reaches critical battery. I have recently learned that our power arrangement will be changing to a parallel-fed/redundant

On October 31, 2017 4:09:46 PM GMT+01:00, Garrett Michael Hayes <Garrett at VerbalImaging.com> wrote: >Greetings Gentlebeings, > >I have started deploying a number of NUT instances on Raspberry Pi >machines (Raspbian Jessie) across my network. The purpose of these >"nutcases" as we refer to them is to monitor the status of the UPSs >supporting our network

I have three APC SmartUPS 5000s. Two of them are AP9617 and one is AP9619. I have a RS-232 connections from my monitor host to all three. All three report status and give information. One of the two AP9617 - ups3-1 - does not shut down when FSD is sent. It did when I first set this system up a year or two ago but it's stopped doing so since then. Resetting the management interface does not