[Nut-upsuser] Re: Newpoint 200897 UPS

[Daniel Gimpelevich]

On Sat, 30 Dec 2006 15:15:45 -0400, Peter Selinger wrote:

> Hi Daniel,
> 
> we have seen device 0d9f/0001 before (possibly under a different name,
> but this is common), and as far as I remember we could not get it to
> work. See the thread named "Gentoo Ultra USB UPS" on nut-upsuser in
> July/August 2006.

Thank you for pointing me to that thread. I did not see it before.

>> /* POWERCOM usage table */
>> static usage_lkp_t powercom_usage_lkp[] = {
>> 	{ "PowercomUPS",			0x00020004 },
>> 	{ "PowercomBatterySystem",		0x00020010 },
>> 	{ "PowercomPowerConverter",		0x00020016 },
>> 	{ "PowercomInput",			0x0002001a },
>> 	{ "PowercomOutput",			0x0002001c },
>> 	{ "PowercomVoltage",			0x00020030 },
>> 	{ "PowercomFrequency",			0x00020032 },
>> 	{ "PowercomPercentLoad",		0x00020035 },
>> 	{ "PowercomTemperature",		0x00020036 },
>> 	{ "PowercomDelayBeforeStartup",		0x00020056 },
>> 	{ "PowercomDelayBeforeShutdown",	0x00020057 },
>> 	{ "PowercomTest",			0x00020058 },
>> 	{ "PowercomShutdownRequested",		0x00020068 },
>> 	{ "PowercomInternalChargeController",	0x00020081 },
>> 	{ "PowercomPrimaryBatterySupport",	0x00020082 },
>> 	{ "PowercomDesignCapacity",		0x00020083 },
>> 	{ "PowercomSpecificationInfo",		0x00020084 },
>> 	{ "PowercomManufacturerDate",		0x00020085 },
>> 	{ "PowercomSerialNumber",		0x00020086 },
>> 	{ "PowercomManufacturerName",		0x00020087 },
>> 	{  "\0", 0x0 }
>> };
> 
> Wow, we didn't have this information before. Is it reliable? Did you
> get this experimentally, or by matching the similar codes in
> drivers/libhid.c?

I got this information using the instructions in hid-subdrivers.txt
exclusively, particularly the part that says where to find usage tables.

> What was the output that you got from 
> drivers/newhidups -DD -u root -x explore -x vendorid=XXXX auto

Unfortunately, I deleted that /tmp/info file shortly after creating it,
since upon examination, pretty much all the info it provided the
path-to-subdriver.sh script already put into the file I attached.

> Would be useful to know if it is indeed similar to the device we saw
> in July/August. The tree back then was:
> 
> Path: 00020004.00020086, Type: Feature, Value: 130.000000
> Path: 00020004.00020087, Type: Feature, Value: 4.000000
> Path: 00020004.00020083, Type: Input
> Path: 00020004.00020085, Type: Input
> Path: 00020004.00020010.00020036, Type: Input
> Path: 00020004.00020010.00020030, Type: Input
> Path: 00020004.00020010.00020084, Type: Input
> Path: 00020004.00020016.0002001a.00020032, Type: Input
> Path: 00020004.00020016.0002001a.00020030, Type: Input
> Path: 00020004.00020016.0002001c.00020030, Type: Input
> Path: 00020004.00020016.0002001c.00020035, Type: Input
> Path: 00020004.00020016.0002001c.00020081, Type: Input
> Path: 00020004.00020016.0002001c.00020082, Type: Input
> Path: 00020004.00020016.0002001c.00020032, Type: Input
> Path: 00020004.00020016.00020058, Type: Feature, Value: 1.000000
> Path: 00020004.00020016.00020068, Type: Feature, Value: 2.000000
> Path: 00020004.00020016.00020057, Type: Feature, Value: 0.000000
> Path: 00020004.00020016.00020056, Type: Feature, Value: 0.000000
> 
> Note that NUT was unable to read values of any of the "Inputs"; only
> the "Features" have readable values. Also note that 130 is an unlikely
> value for "SerialNumber". 

Well, I don't know what to say about that. The serial number printed on
the box it came in is 20096230603, and as you could see, upsc reported an
empty string for it.