Open GoogleCodeExporter opened 9 years ago
ok, found the way at hidapi/README
Original comment by and7ey@gmail.com
on 11 Sep 2011 at 3:27
i am having the same issue. I am running 2.6.16. I couldnt find anything in
hipapi/README to avoid hidraw usage. Can you help me?
Original comment by srkrish...@gmail.com
on 21 Sep 2011 at 12:41
[deleted comment]
Correct path is cpp/hidapi/linux/README.TXT
Try to change hid.c to hid-libusb.c in the main Makefile (cpp/build/linux).
Which device you are trying to compile that for?
Original comment by and7ey@gmail.com
on 21 Sep 2011 at 3:01
Linux 2.6.16 is over *six* years old. Even if we were to fix the library to
avoid hid usage, which is entirely possible, this is an ancient kernel. Please
use a modern system.
Original comment by pnau...@gmail.com
on 21 Sep 2011 at 3:49
In some cases this is not possible, unfortunately.
My router's firmware uses this old version of linux since new version doesn't
work with WiFi driver and sources of that driver are closed.
Original comment by and7ey@gmail.com
on 21 Sep 2011 at 3:58
You are trying to have it both ways. If you use old vendor-supplied firmware,
you are going to have problems. I can say that from multiple first-hand
experience. Asking the openzwave developers to support your ancient system is
a bit silly.
So, you have a couple of choices:
* Use a modern embedded distro (e.g, OpenWrt)
* Use better hardware with a fully open system
* Update openzwave yourself to not required support of those modern parts, and
send some patches. But you are likely to run into other issues still.
If you really need to do the last option, it should be a simple matter of
#ifdefs and makefile flags.
Original comment by pet...@candicontrols.com
on 21 Sep 2011 at 7:03
and7ey did you ever get this sorted out? I'm trying to get open-zwave running
on an ASUS RT-N16 with DD-WRT running kernel 2.6.24.111.
Original comment by calebesk...@gmail.com
on 14 Jan 2013 at 6:38
calebeskurdal, unfortunately, no. I had to use z-connector instead.
Original comment by and7ey@gmail.com
on 15 Jan 2013 at 4:27
[deleted comment]
Hello all,
I am having some troubles with the way hidController.cpp is implemented.
First thing the vendorId and productId are hard coded for a specific controller
from a specific vendor if you want to use usblib with another product from a
different vendor then you have to modify the reference provided in
hidcontroller.cpp file.
Logically those vendorId productId should come from a list of recognized
controller and compared with listed device returned by udev.
Then the hid means Human Input Device ! normally usb device attached to hidraw
are keyboard mouse, drawing tablets etc.. in short what allows the use to
interact with a computer.
So why should a z-wave modem static controller be identified by udev as a
device that would be depending on HID and attached to hidraw?
For instance udev on my arch linux (lastest kernel /udev from 1 day ago update)
the Z-Wave controller I use is referenced as a Communicator device type not as
a Human Interface Device device type. So it is attached to the usb tree and not
to the hid tree in udev.
I agree that having this usbcontroller is a great thing, but it should be more
flexible and allow auto detection of hardware like it is intended to do.
Original comment by shada...@gmail.com
on 27 Feb 2015 at 6:23
The HIDController code is for Controllers that implement the HID instead of
Serial interface. There were several older controllers that do this, but I've
not seen any recent controllers use it.
It defaults to the only HID controller that was released (TrickleStar) but is
modifiable via the ManagerAPI Class, so its not "Hardcoded" just defaulted.
Since you controller is using the Communication class then use the Serial API.
Your assumptions about its capabilities are incorrect. :)
If you are using a USB controller that emulates the Serial interface
(/dev/ttyUSB* etc) then you should be using the Serial Interface instead (the
default).
Original comment by jus...@dynam.ac
on 2 Mar 2015 at 1:41
[deleted comment]
Justin thank you for your reply.
The goal of HId interface in openzwave is more clear now.
Ofcourse ideally I would like to get the openzwave library talking to udev to
auto detect the zwave controller and retrieve the port that the library should
use.
but it s alot of work for something that will eventually work.
While letting the user seek and provide the communication port to use in openzwave library will always work.
Original comment by shada...@gmail.com
on 2 Mar 2015 at 3:50
No need to get so complicated. Just create a udev rule that maps your
Controller to a static device node. (/dev/zwave for example)
Something like this:
ACTION=="remove", GOTO="zwave_controller"
SUBSYSTEM=="usb-serial" ATTRS{idVendor}=="XXXX" ATTRS{idProduct}=="XXXX"
SYMLINK+="zwave"
LABEL="zwave_controller"
You probably have to modify the ATTRS entries to match your ZWave Controller,
or add different attributes, but the concept is the same.
Original comment by jus...@dynam.ac
on 3 Mar 2015 at 2:47
[deleted comment]
Hi justin, I ended doing exactly this. if my symlink udev port doesn t exists
and the udev rule file doesn t exists then I create it with the proper idVendor
and idProduct match for my zwave controller.
you can retreive idVendor and idProduct with udevadm info -a -n /dev/ttyUSB0 |
grep idProduct or idVendor.
Thank you again.
Original comment by shada...@gmail.com
on 12 Mar 2015 at 3:46
Original issue reported on code.google.com by
and7ey@gmail.com
on 8 Sep 2011 at 7:50