Nut upsdev - Dec 2005 - Atlantis-Land UPS with Cypress CY7C63723 chip (cypress_m8 driver) support

Hello everybody!

   I am trying to get an Atlantis-Land OnePower Line Interactive S1501 
UPS (actually it is made by Ablerex) to talt to my Linux box through its 
USB port (no more RS-232...), either using the supplied program 
(UPSilon2000, works under Win and Linux) or whatever else.

   The UPSilon2000 program apparently works OK *if* it can talk to the 
UPS via a serial port; since my UPS has a USB port, no luck (I get a 
series of error messages). On the other hand, I verified the UPSilon2000 
works OK under Windoze, again through the USB port.

   The error I get is:
drivers/usb/input/hid-core.c: couldn't find an input interrupt endpoint
usbhid: probe of 3-2:1.0 failed with error -5

   I opened the UPS and found a Cypress CY7C63723-PC chip. So I wrote to 
Lonnie Mendez, the maintainer of the cypress_m8 driver; this is what he 
replied (quoting with permission):

 >  Yes, the CY7C63723 is in the family.  However in this instance, the 
device seems
 > to go by the standards defined in the HID documentation at usb.org 
(notice the several
 > usage definitions given by the hid report descriptor).  So the 
cypress_m8 driver will most
 > definitely NOT work with this device (ie: it doesn't go by the CY4601 
specifications, which
 > needs 2 interrupt endpoints).

 >  I'd email the developers over at networkupstools.org (the guys that 
made NUT) the entire lsusb -v output you gave me
 > from the BusID all the way down to the last usage in the hid report 
descriptor.  They can most likely
 > use this information to add support for this device, as it seems to 
go by some standards... at least under
 > the usb.org HID specification for UPS devices.

   Before I post the entire lsusb output and generate a lot of noise on 
the list, I just wanted to be sure this is the right list for this kind 
of questions. Please do let me know.

Many thanks in advance for your attention.

Max

On 12/7/05, ngpost1 <ngpost1@etitech.net> wrote:
>  >  I'd email the developers over at networkupstools.org (the guys
that
> made NUT) the entire lsusb -v output you gave me
>  > from the BusID all the way down to the last usage in the hid report
> descriptor.  They can most likely
>  > use this information to add support for this device, as it seems to
> go by some standards... at least under
>  > the usb.org HID specification for UPS devices.
Agreed, that information would be useful to figure out where to go next.
>    Before I post the entire lsusb output and generate a lot of noise on
> the list, I just wanted to be sure this is the right list for this kind
> of questions. Please do let me know.
The nut-upsdev list is a little more oriented towards NUT driver
development. But if you don't want to subscribe to another list just
yet, and just want a quick "can it be done, and how easily?"
assessment, posting a couple technical tidbits here shouldn't be much
of a problem.

--
- Charles Lepple

Thank to Charles and Arnaud for your replies.

At this point, I am posting (with permission) my mail exchange with 
Lonnie Mendez, along with the lsusb output.


 Basically, as Lonnie put it, the chip works as a HID device (and I can 
confirm on that), so it should be supported under NUT.

 I am absolutely no expert on the matter of USB. The only thing I can do 
(and most happily!) is test whatever is available, since I have this UPS 
that desperately needs to be interfaced.

Thanks in advance for your attention and help.


--Max

============================================================================= 

Hello!

I have an UPS made by Ablerex, it's a Vesta 1500  (see  
http://www.uisabler.com.tw/HTM/product-lineinteractive.htm ) , rebranded 
as Atlantis-Land (model A03-S1501, see 
http://www.atlantis-land.com/prodotti.php?catID=22 ).

Inside the unit (I opened it) there is a Cypress CY7C63723-PC chip 
which, according the Documentation/usb/usb-serial.txt, should be 
supported just fine by your driver. Also, a search on the Cypress site 
confirms that the 7C63723 belongs to the CY4601 family.

Unfortunately, when I connect the UPS to the USB port (tried on several 
PC's and notebooks) I get a

drivers/usb/input/hid-core.c: couldn't find an input interrupt endpoint
usbhid: probe of 3-2:1.0 failed with error -5


error from dmesg. This guy over here has exactly the same problems I am 
experiencing:

http://www.mail-archive.com/linux-usb-users@lists.sourceforge.net/msg14649.html 


I understand if all goes well the UPS's port should show up as 
/dev/ttyUSB0 or something, but this is not my case. I tried  searching 
online without results. I also tried reading the driver source, but I am 
all but a kernel hacker and got lost pretty soon.

I am quite lost; moreover, I cannot understand if the problem is kernel 
related or driver related (therefore I have no idea where I should post 
for help). I am posting the output of dmesg below.

Thanks in advance for your attention and best regards.

P.S.: These come from a machine running Fedora Core 2 (old, I know); but 
I got the same results with the latest Mepis and Knoppix 3.9 as well.


This is from dmesg:

Sep 27 15:23:27 fc2 kernel: usb 1-2: new low speed USB device using 
uhci_hcd and address 3
Sep 27 15:23:27 fc2 kernel: drivers/usb/input/hid-core.c: couldn't find 
an input interrupt endpoint
Sep 27 15:23:27 fc2 kernel: usbhid: probe of 1-2:1.0 failed with error -5




This is an lsusb -v:   [please see attached file 
Atlantis-land_lsusb.txt.gz]



------------------------------------------------------------------------
On Tuesday 27 September 2005 8:33 am, you wrote:
> > Hello!
> > >    I have an UPS made by Ablerex, it's a Vesta 1500  (see 
>
> http://www.uisabler.com.tw/HTM/product-lineinteractive.htm ) , 
> rebranded > as Atlantis-Land (model A03-S1501, see > 
> http://www.atlantis-land.com/prodotti.php?catID=22 ).
> > >    Inside the unit (I opened it) there is a Cypress CY7C63723-PC 
> chip > which, according the Documentation/usb/usb-serial.txt, should 
> be > supported just fine by your driver. Also, a search on the Cypress 
> site > confirms that the 7C63723 belongs to the CY4601 family.
> >   
  Yes, the CY7C63723 is in the family.  However in this instance, the 
device seems
to go by the standards defined in the HID documentation at usb.org 
(notice the several
usage definitions given by the hid report descriptor).  So the 
cypress_m8 driver will most
definitely NOT work with this device (ie: it doesn't go by the CY4601 
specifications, which
needs 2 interrupt endpoints).

> >    Unfortunately, when I connect the UPS to the USB port (tried on
>
> several PC's and notebooks) I get a
> > > drivers/usb/input/hid-core.c: couldn't find an input
interrupt
> endpoint
> > usbhid: probe of 3-2:1.0 failed with error -5
> >
>   
  Sounds about right.  The hid-core needs at least an interrupt input 
endpoint to function.
This device seems to do all communication through endpoint zero, which 
would be
control trasactions using the HID specification for UPS devices at 
usb.org.  The device
on unix will most likely being doing coummication through NUT, which 
would use libusb.
See further down.
> > >    error from dmesg. This guy over here has exactly the same 
> problems I > am experiencing:
> > > 
>
http://www.mail-archive.com/linux-usb-users@lists.sourceforge.net/msg14649.html
>
> > >    I understand if all goes well the UPS's port should show
up as
> > /dev/ttyUSB0 or something, but this is not my case. I tried  
> searching > online without results. I also tried reading the driver 
> source, but I am > all but a kernel hacker and got lost pretty soon.
> > >    I am quite lost; moreover, I cannot understand if the problem 
> is > kernel related or driver related (therefore I have no idea where 
> I > should post for help). I am posting the output of dmesg below.
>   
  I'd email the developers over at networkupstools.org (the guys that 
made NUT) the entire lsusb -v output you gave me
from the BusID all the way down to the last usage in the hid report 
descriptor.  They can most likely
use this information to add support for this device, as it seems to go 
by some standards... at least under
the usb.org HID specification for UPS devices.  However, the idVendor 
and idProduct values looks very funny.
0001 and 0000.  idVendor might be invalid (ie: they didn't want to pay 
usb.org for a valid number id) and you could potentially
run into conflicts with devices which are valid for idVendor being 0001.

 -Lonnie


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Atlantis-land_lsusb.txt.gz
Type: application/gzip
Size: 3175 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20051209/e5b836fd/Atlantis-land_lsusb.txt.bin

On 12/9/05, ngpost1 <ngpost1@etitech.net> wrote:
> Thank to Charles and Arnaud for your replies.
>
> At this point, I am posting (with permission) my mail exchange with
> Lonnie Mendez, along with the lsusb output.
>
>
>  Basically, as Lonnie put it, the chip works as a HID device (and I can
> confirm on that), so it should be supported under NUT.
Here is Peter Selinger's recipe for getting started with newhidups:

   drivers/newhidups -u root -DD -x generic auto

I can't remember exactly what version (source snapshot) of the code
provides the 'generic HID' support, but it may be worth the time to
get CVS set up. That way, if any changes are needed, you can just
update your working copy, and test them.

CVS instructions are here:

   http://www.networkupstools.org/source.html

--
- Charles Lepple

Hello everybosy!

   So far, so good.

   Compiled and installed everything according to the documentation. 
Now, when I plug in the USB I get from /var/log/messages:

[root@testbox ~]# tail -f /var/log/messages
Dec 13 14:25:13 testbox sshd(pam_unix)[1419]: session opened for user 
root by root(uid=0)
Dec 13 14:25:28 testbox sshd(pam_unix)[1445]: session opened for user 
root by root(uid=0)
Dec 13 14:27:25 testbox kernel: usb 1-1: new low speed USB device using 
ohci_hcd and address 2
Dec 13 14:27:26 testbox kernel: drivers/usb/input/hid-core.c: couldn't 
find an input interrupt endpoint
Dec 13 14:27:37 testbox kernel: usbcore: registered new driver yealink
Dec 13 14:27:37 testbox kernel: drivers/usb/input/yealink.c: Yealink 
phone driver:yld-20050816

It still reports that it can't find an interrupt endpoint, but at least 
the "usbhid: probe of 3-2:1.0 failed with error -5" is gone. Funny, it
thinks it's a Yealink phone!

Anyway, here's what newhidups reports (note that I had to use the 
vendorid option):

[root@testbox conf.d]# /usr/local/ups/bin/newhidups -u root -DD -x 
generic -x vendorid=0001 auto
Network UPS Tools: New USB/HID UPS driver 0.28 (2.1.0)

debug level is '2'
Checking device (0001/0000) (001/002)
- VendorID: 0001
- ProductID: 0000
- Manufacturer: UIS_ABLER
- Product: USB to Serial
- Serial Number: unknown
- Bus: 001
Trying to match device
Device matches
HID descriptor retrieved (Reportlen = 632)
Report descriptor retrieved (Reportlen = 632)
Found HID device
Report Descriptor size = 632
Detected a UPS: UIS_ABLER/USB to Serial
Using subdriver: GENERIC HID 0.1
Path: 00860004.Flow.FlowID, Type: Feature, Value: 0.000000
Path: 00860004.Flow.ConfigVoltage, Type: Feature, Value: 0.000000
Path: 00860004.Flow.ConfigFrequency, Type: Feature, Value: 0.000000
Path: 00860004.Flow.LowVoltageTransfer, Type: Feature, Value: 0.000000
Path: 00860004.Flow.HighVoltageTransfer, Type: Feature, Value: 0.000000
Path: 00860004.Flow.iManufacturer, Type: Feature, Value: 0.000000
Path: 00860004.Flow.iProduct, Type: Feature, Value: 0.000000
Path: 00860004.Flow.iSerialNumber, Type: Feature, Value: 0.000000
Path: 00860004.Flow.FlowID, Type: Feature, Value: 0.000000
Path: 00860004.Flow.ConfigVoltage, Type: Feature, Value: 0.000000
Path: 00860004.Flow.ConfigFrequency, Type: Feature, Value: 0.000000
Path: 00860004.Flow.ConfigApparentPower, Type: Feature, Value: 0.000000
Path: 00860004.Flow.ConfigActivePower, Type: Feature, Value: 0.000000
Path: 00860004.Flow.DelayBeforeStartup, Type: Feature, Value: 0.000000
Path: 00860004.Flow.DelayBeforeShutdown, Type: Feature, Value: 0.000000
Path: 00860004.BatterySystem.BatterySystemID, Type: Feature, Value: 0.000000
Path: 00860004.BatterySystem.PresentStatus.Used, Type: Feature, Value: 
0.000000
Path: 00860004.BatterySystem.PresentStatus.Good, Type: Feature, Value: 
0.000000
Path: 00860004.BatterySystem.Voltage, Type: Feature, Value: 0.000000
Path: 00860004.BatterySystem.Temperature, Type: Feature, Value: 0.000000
Path: 00860004.BatterySystem.Test, Type: Input, Value: 0.000000
Path: 00860004.BatterySystem.Test, Type: Feature, Value: 0.000000
Can't find object 00860004.PowerConverter.PowerConverterID
Path: 00860004.PowerConverter.PowerConverterID, Type: Input
Can't find object 00860004.PowerConverter.Input.InputID
Path: 00860004.PowerConverter.Input.InputID, Type: Input
Can't find object 00860004.PowerConverter.Input.FlowID
Path: 00860004.PowerConverter.Input.FlowID, Type: Input
Can't find object 00860004.PowerConverter.Input.PresentStatus.Good
Path: 00860004.PowerConverter.Input.PresentStatus.Good, Type: Input
Can't find object 00860004.PowerConverter.Input.Voltage
Path: 00860004.PowerConverter.Input.Voltage, Type: Input
Can't find object 00860004.PowerConverter.Input.Frequency
Path: 00860004.PowerConverter.Input.Frequency, Type: Input
Can't find object 00860004.PowerConverter.Output.OutputID
Path: 00860004.PowerConverter.Output.OutputID, Type: Input
Can't find object 00860004.PowerConverter.Output.FlowID
Path: 00860004.PowerConverter.Output.FlowID, Type: Input
Can't find object 00860004.PowerConverter.Output.Voltage
Path: 00860004.PowerConverter.Output.Voltage, Type: Input
Can't find object 00860004.PowerConverter.Output.Frequency
Path: 00860004.PowerConverter.Output.Frequency, Type: Input
Can't find object 00860004.PowerConverter.Output.PercentLoad
Path: 00860004.PowerConverter.Output.PercentLoad, Type: Input
Can't find object 00860004.PowerConverter.Output.PresentStatus.Overload
Path: 00860004.PowerConverter.Output.PresentStatus.Overload, Type: Input
Can't find object 00860004.PowerConverter.Output.PresentStatus.Boost
Path: 00860004.PowerConverter.Output.PresentStatus.Boost, Type: Input
Can't find object 00860004.PowerConverter.Output.PresentStatus.Buck
Path: 00860004.PowerConverter.Output.PresentStatus.Buck, Type: Input
Path: 00860004.PowerConverter.Output.PresentStatus.00840039, Type: 
Feature, Value: 0.000000
entering identify_ups(0x0001, 0x0000)

upsdrv_updateinfo...
dstate_init: sock /var/state/ups/newhidups-auto open on fd 5
upsdrv_updateinfo...
Waiting for notifications...
upsdrv_updateinfo...
Waiting for notifications...
Signal 2: exiting
Closing device
[root@testbox ~]#

   Apparently the UPS is recognized but no communication is occurring. 
What else? lsmod shows the yealink driver loaded. I attached the lsusb 
output.
   If I ls the /dev directory, there are no ttyUSBxx nodes. Only tty's 
and ttySxx. I believe there should be a ttyUSBsomething being created, 
and this should be entered in the ups.conf file.

   Any suggestions?

Many thanks in advance

  --Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lsusb.txt.gz
Type: application/gzip
Size: 2314 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20051213/aa1adddb/lsusb.txt.bin

[I am moving this threat to the nut-upsdev list from the nut-upsuser
list]

ngpost1 wrote:
> 
> Hello everybosy!
> 
>    So far, so good.
> 
>    Compiled and installed everything according to the documentation. 
> Now, when I plug in the USB I get from /var/log/messages:
> 
> [root@testbox ~]# tail -f /var/log/messages
> Dec 13 14:25:13 testbox sshd(pam_unix)[1419]: session opened for user 
> root by root(uid=0)
> Dec 13 14:25:28 testbox sshd(pam_unix)[1445]: session opened for user 
> root by root(uid=0)
> Dec 13 14:27:25 testbox kernel: usb 1-1: new low speed USB device using 
> ohci_hcd and address 2
> Dec 13 14:27:26 testbox kernel: drivers/usb/input/hid-core.c: couldn't 
> find an input interrupt endpoint
> Dec 13 14:27:37 testbox kernel: usbcore: registered new driver yealink
> Dec 13 14:27:37 testbox kernel: drivers/usb/input/yealink.c: Yealink 
> phone driver:yld-20050816
> 
> It still reports that it can't find an interrupt endpoint, but at least
> the "usbhid: probe of 3-2:1.0 failed with error -5" is gone.
Funny, it
> thinks it's a Yealink phone!
This does not matter. The kernel has a habit of looking at USB
devices, because they could be mice, keyboards, disk drives, or
similar stuff that the kernel cares about. However, for UPS devices,
we use a user space driver such as newhidups and not a kernel driver.
So it doesn't matter what the kernel thinks.
> Anyway, here's what newhidups reports (note that I had to use the 
> vendorid option):
Correct.
 
> [root@testbox conf.d]# /usr/local/ups/bin/newhidups -u root -DD -x 
> generic -x vendorid=0001 auto
> Network UPS Tools: New USB/HID UPS driver 0.28 (2.1.0)
> 
> debug level is '2'
> Checking device (0001/0000) (001/002)
> - VendorID: 0001
> - ProductID: 0000
> - Manufacturer: UIS_ABLER
> - Product: USB to Serial
> - Serial Number: unknown
> - Bus: 001
> Trying to match device
> Device matches
> HID descriptor retrieved (Reportlen = 632)
> Report descriptor retrieved (Reportlen = 632)
> Found HID device
> Report Descriptor size = 632
> Detected a UPS: UIS_ABLER/USB to Serial
> Using subdriver: GENERIC HID 0.1
> Path: 00860004.Flow.FlowID, Type: Feature, Value: 0.000000
> Path: 00860004.Flow.ConfigVoltage, Type: Feature, Value: 0.000000
> Path: 00860004.Flow.ConfigFrequency, Type: Feature, Value: 0.000000
> Path: 00860004.Flow.LowVoltageTransfer, Type: Feature, Value: 0.000000
> Path: 00860004.Flow.HighVoltageTransfer, Type: Feature, Value: 0.000000
> Path: 00860004.Flow.iManufacturer, Type: Feature, Value: 0.000000
> Path: 00860004.Flow.iProduct, Type: Feature, Value: 0.000000
> Path: 00860004.Flow.iSerialNumber, Type: Feature, Value: 0.000000
> Path: 00860004.Flow.FlowID, Type: Feature, Value: 0.000000
> Path: 00860004.Flow.ConfigVoltage, Type: Feature, Value: 0.000000
> Path: 00860004.Flow.ConfigFrequency, Type: Feature, Value: 0.000000
> Path: 00860004.Flow.ConfigApparentPower, Type: Feature, Value: 0.000000
> Path: 00860004.Flow.ConfigActivePower, Type: Feature, Value: 0.000000
> Path: 00860004.Flow.DelayBeforeStartup, Type: Feature, Value: 0.000000
> Path: 00860004.Flow.DelayBeforeShutdown, Type: Feature, Value: 0.000000
> Path: 00860004.BatterySystem.BatterySystemID, Type: Feature, Value:
0.000000
> Path: 00860004.BatterySystem.PresentStatus.Used, Type: Feature, Value: 
> 0.000000
> Path: 00860004.BatterySystem.PresentStatus.Good, Type: Feature, Value: 
> 0.000000
> Path: 00860004.BatterySystem.Voltage, Type: Feature, Value: 0.000000
> Path: 00860004.BatterySystem.Temperature, Type: Feature, Value: 0.000000
> Path: 00860004.BatterySystem.Test, Type: Input, Value: 0.000000
> Path: 00860004.BatterySystem.Test, Type: Feature, Value: 0.000000
> Can't find object 00860004.PowerConverter.PowerConverterID
> Path: 00860004.PowerConverter.PowerConverterID, Type: Input
> Can't find object 00860004.PowerConverter.Input.InputID
> Path: 00860004.PowerConverter.Input.InputID, Type: Input
> Can't find object 00860004.PowerConverter.Input.FlowID
> Path: 00860004.PowerConverter.Input.FlowID, Type: Input
> Can't find object 00860004.PowerConverter.Input.PresentStatus.Good
> Path: 00860004.PowerConverter.Input.PresentStatus.Good, Type: Input
> Can't find object 00860004.PowerConverter.Input.Voltage
> Path: 00860004.PowerConverter.Input.Voltage, Type: Input
> Can't find object 00860004.PowerConverter.Input.Frequency
> Path: 00860004.PowerConverter.Input.Frequency, Type: Input
> Can't find object 00860004.PowerConverter.Output.OutputID
> Path: 00860004.PowerConverter.Output.OutputID, Type: Input
> Can't find object 00860004.PowerConverter.Output.FlowID
> Path: 00860004.PowerConverter.Output.FlowID, Type: Input
> Can't find object 00860004.PowerConverter.Output.Voltage
> Path: 00860004.PowerConverter.Output.Voltage, Type: Input
> Can't find object 00860004.PowerConverter.Output.Frequency
> Path: 00860004.PowerConverter.Output.Frequency, Type: Input
> Can't find object 00860004.PowerConverter.Output.PercentLoad
> Path: 00860004.PowerConverter.Output.PercentLoad, Type: Input
> Can't find object 00860004.PowerConverter.Output.PresentStatus.Overload
> Path: 00860004.PowerConverter.Output.PresentStatus.Overload, Type: Input
> Can't find object 00860004.PowerConverter.Output.PresentStatus.Boost
> Path: 00860004.PowerConverter.Output.PresentStatus.Boost, Type: Input
> Can't find object 00860004.PowerConverter.Output.PresentStatus.Buck
> Path: 00860004.PowerConverter.Output.PresentStatus.Buck, Type: Input
> Path: 00860004.PowerConverter.Output.PresentStatus.00840039, Type: 
> Feature, Value: 0.000000
> entering identify_ups(0x0001, 0x0000)
> 
> upsdrv_updateinfo...
> dstate_init: sock /var/state/ups/newhidups-auto open on fd 5
> upsdrv_updateinfo...
> Waiting for notifications...
> upsdrv_updateinfo...
> Waiting for notifications...
> Signal 2: exiting
> Closing device
> [root@testbox ~]#
This is useful information. I don't think the device is currently
supported, but the information printed above is enough to write a
subdriver for it. Note that the purpose of the "-x generic" option is
precisely to produce this output. 
>    Apparently the UPS is recognized but no communication is occurring. 
> What else? lsmod shows the yealink driver loaded. I attached the lsusb 
> output.
>    If I ls the /dev directory, there are no ttyUSBxx nodes. Only tty's 
> and ttySxx. I believe there should be a ttyUSBsomething being created, 
> and this should be entered in the ups.conf file.
No, USB devices are handled through /proc/bus/usb, not /dev/tty*.
 
>    Any suggestions?
I don't have time right now to work on a new subdriver, but you can
look at docs/hid-subdrivers.txt and that should give you an idea on
how to get started. Once you get something to work, you can post your
code and results on this list, and if it works well, we'll add it as a
supported device to NUT.

Thanks for your detective work, -- Peter