[Nut-upsuser] suse linux and nut

[Peter Selinger]

Marc Collin wrote:
> 
> Le samedi 26 ao=FBt 2006 19:45, Peter Selinger a =E9crit=A0:
> > Marc Collin wrote:
> > > linux64:/home/collinm/Download/trunk # /usr/local/ups/bin/upsc
> > > myups at localhost driver.name: newhidups
> > > driver.parameter.port: /dev/hiddev0
> > > driver.version: 2.1.0
> > > driver.version.data: PowerCom HID 0.1
> > > driver.version.internal: 0.30
> > > powercom.coll2.feature3: 1
> > > powercom.coll2.feature4: 2
> > > powercom.coll2.feature5: 0
> > > powercom.coll2.feature6: 0
> > > powercom.feature1: 130
> > > powercom.feature2: 54
> > > ups.mfr: PowerCom
> >
> > Good, this is what I wanted to see. The next step: please experiment
> > to see which of the powercom.* values change in response to events
> > (loss of power, on battery, low battery, battery charging, battery
> > full, etc). The point is that we will have to guess how to compute
> > "ups.status" from the values. The "low battery" condition is
> > especially important, as it is used by upsmon.
> >
> > My guesses so far:
> >
> > powercom.coll2.feature3: 1    -- don't know; perhaps a status flag
> > powercom.coll2.feature4: 2    -- don't know; perhaps a status flag
> > powercom.coll2.feature5: 0    -- don't know; perhaps a status flag
> > powercom.coll2.feature6: 0    -- don't know; perhaps a status flag
> > powercom.feature1: 130        -- perhaps a line voltage? (depends on
> > country) powercom.feature2: 54         -- perhaps a battery voltage or
> > charge level?
> >
> > -- Peter
> 
> i live in canada

Oh good, so do I!

> don't know if it's usefull but i runned a windows program for the ups in
> vmware.... i used usbsnoop
> 
> the log file is available at:
> 
> http://www.laboiteaprog.com/usbsnoop.log

Yes, that's actually useful. It shows that the Windows driver
exclusively uses interrupt transfers, something that newhidups is not
yet very good at. Decoding the transmitted values by hand, I get the
following. The values in [brackets] are decimal, and are arrays. 

POWERCOM_UPS.POWERCOM_Input2: [255, 99]
POWERCOM_UPS.POWERCOM_Coll1.POWERCOM_Input4: [0, 97]
POWERCOM_UPS.POWERCOM_Coll1.POWERCOM_Input5: 0x6a6e7a
POWERCOM_UPS.POWERCOM_Coll2.POWERCOM_Sub1.POWERCOM_Input4: [60, 30]
POWERCOM_UPS.POWERCOM_Coll2.POWERCOM_Sub2.POWERCOM_Input6: [30, 15, 0, 64, 60]

I see 97 in POWERCOM_UPS.POWERCOM_Coll1.POWERCOM_Input4 (this could be
the battery level), and 60 in two places. I also see 15. I don't see
anything that looks like a voltage, except perhaps the 0x7a = 122 in
POWERCOM_UPS.POWERCOM_Coll1.POWERCOM_Input5. 

What's to do here for the NUT developers is: first, improve support
for interrupt transfers in newhidups. Also add support for arrays
(usage items with a usage count of >1). Then figure out how to map
these items.

> i see with the gui program
> I/P VOLTAGE: 120
> O/P VOLTAGE: 120
> LOAD LEVEL: 15
> I/P FREQUENCY 60
> O/P FREQUENCY 60
> BATTERY LEVEL 97
 

> when i unplug the ups  data don't changed
> 
> linux64:/home/collinm/Download/trunk # /usr/local/ups/bin/upsc myups at localh=
> ost
> driver.name: newhidups
> driver.parameter.port: /dev/hiddev0
> driver.version: 2.1.0
> driver.version.data: PowerCom HID 0.1
> driver.version.internal: 0.30
> powercom.coll2.feature3: 1
> powercom.coll2.feature4: 2
> powercom.coll2.feature5: 0
> powercom.coll2.feature6: 0
> powercom.feature1: 130
> powercom.feature2: 170
> ups.mfr: PowerCom

It looks to me like the data changed in powercom.feature2: 170 is not
the same as 54. Not sure what it means though. In hexadecimal, 170 =
0xaa and 54 = 0x36.  The changes are in too many bits; this does not
look like a status flag to me.

> linux64:/home/collinm # /usr/local/ups/sbin/upsmon -DDD -u root
> Network UPS Tools upsmon 2.1.0
> UPS: myups at localhost (master) (power value 1)
> Using power down flag file /etc/killpower

Don't use upsmon yet. There is nothing to monitor until the driver
supports this device.

-- Peter