Open GoogleCodeExporter opened 9 years ago
Peter made a Linux only patch that I modularized so it could be stubbed out for
the other hardware platforms (Mac, Windows). I never committed it because not
many people have expressed a need to pull their controller from the USB port
and it wasn't a very clean patch. Seems like a good time to revisit this issue.
Original comment by glsatz
on 3 Nov 2012 at 3:35
Ok it would be nice to include that patch in a revision of OZW, maybe we can
also have a look to serial port handling if we unplug and replug it again? I
like to call these enhancements more "stability" fixes (now OZW is getting more
mature - then we need such code more i think).
Original comment by uAle...@gmail.com
on 3 Nov 2012 at 4:05
Ok. I will need someone to verify a windows (stub) patch.
Original comment by glsatz
on 3 Nov 2012 at 4:57
Peter's original email about his patch:
https://groups.google.com/forum/#!topic/openzwave/2VdGhj77i8Q/discussion
Note this adds a new dependency to the Linux build, libudev.
Original comment by glsatz
on 4 Nov 2012 at 7:14
Adding the libudev dependency i don't see as a (major) issue, because we get
more stability back for it.
Other question, can we add 2 types of notification to allow the main program to
known the serial port is unavailable (when e.g. disconnect) and available
again? Currently i don't have any good way to allow my main program to know the
Open Z-Wave library is working fine or not.
Original comment by uAle...@gmail.com
on 4 Nov 2012 at 8:35
Here is the patch Peter did updated so the platform specific code lives in
different files instead of using #ifdefs. Not sure this patch is very useful as
it only checks for the presence of the USB controller at open time. Pulling the
USB controller still needs to be detected elsewhere. I am not planning on
committing this patch until we have some better understanding on where and how
USB controller presence should be managed. Peter reported that he wound up
moving his detection code into his user program and use the manager object
calls to open and close the driver. More discussion is needed.
Original comment by glsatz
on 5 Nov 2012 at 5:34
Attachments:
Commets from Peter on how he did this under Linux:
Both the original and the current code I have are essentially stock example udev
code. See the monitor stuff:
http://www.signal11.us/oss/udev/
There are a few changes because it's a serial port, but those are already
in the code you have.
In my main loop, I have a select loop anyway, so this is just another
file descriptor to monitor. It's very easy.
Original comment by glsatz
on 13 Nov 2012 at 8:26
Going down the USB route is overkill if you ask me.
The 100% CPU spin was caused in the Read Member function of the SerialImpl
class. (not tried/looked at the HID or Windows version). Its root cause was
that we were not testing for the read system call returning 0 (by the look of
the code, the original author assumed read returning 0 indicated no data. In
fact as we are in blocking mode, read returning 0 indicates EOF)
The second problem is that there is no error path upto the Driver (or
eventually) the Manager class to indicate errors. Thus the driver would happy
keep trying to read/write etc and the manager (and thus the application) had no
idea there was a problem)
Attached is a WIP patch, that adds some error handling to at least get the
Error upto the driver class. I'm still trying to propogate that error to the
Manager class so we can unload the driver and at least have the driver die
gracefully, but there is still a loop somewhere in the WriteMsg functions etc.
I'll revist this patch after the Security Class has settled down a bit.
Original comment by jus...@dynam.ac
on 12 Jun 2014 at 11:53
Attachments:
Thanks, i will apply the patch on my system and give it a try. Yes, telling via
a notification, that the device is gone, is a valuable addition to open-zwave
(but the Security Class first :-)).
Original comment by uAle...@gmail.com
on 12 Jun 2014 at 11:59
Hi, as mentioned, the patch isn't complete. It's just moved the bug to
somewhere around WriteMsg in the driver class. Feel free to improve it though!
Original comment by jus...@dynam.ac
on 12 Jun 2014 at 4:17
I tested the patch and it doesn't generate a 100% cpu anymore on the
disconnect, but the driver is now looping in itself as you mentioned (and then
again 100% cpu again) ;-)
Original comment by uAle...@gmail.com
on 21 Jun 2014 at 11:23
Original comment by jus...@dynam.ac
on 15 Oct 2014 at 2:56
Original comment by jus...@dynam.ac
on 15 Oct 2014 at 2:58
Original issue reported on code.google.com by
uAle...@gmail.com
on 3 Nov 2012 at 11:37