BU353 returns "FileNotFoundException: /dev/ttyUSB0 (Device or resource busy)"

[hekonsek]

I'm unable to use the GpsBu353Component. I connected my Bu353S4 receiver to my Raspberry Pi (Raspbian) which is working fine. That means gpsd is running and cgps prints out valid coordinates. But when I run your camel example on the raspberry, I always get the following exception:

Consumer Consumer[gps-bu353://current-position] failed polling endpoint: Endpoint[gps-bu353://current-position]. Will try again at next poll. Caused by: [java.lang.RuntimeException - java.io.FileNotFoundException: /dev/ttyUSB0 (Device or resource busy)].

The "fuser" command tells me, that the java process running camel is actually the only process that accesses ttyUSB0. Can you help me?

[hekonsek]

Hi Thomas,

Have you tried to run the route again after the restart of the device? Please be sure that you don't run the cgps command before running the route.

[thberger]

Hi, would be great if we can get the Bu353 to fly with camel. I just tried what you suggested, but now with the result that the component has problems to restart the daemon. Here is the output of what I did:

---> Disconnect the Bu353 from USB port
pi@camelpi ~ $ sudo reboot now
pi@camelpi ~ $ uname -a
Linux camelpi 4.1.7+ #817 PREEMPT Sat Sep 19 15:25:36 BST 2015 armv6l GNU/Linux
pi@camelpi ~ $ gpsd -V
gpsd: 3.6 (revision 3.6)
-------> Now I attach the Bu353 via USB
pi@camelpi ~ $ lsusb | grep Prolific
Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
pi@camelpi ~/deploy $ java -jar camel-gps-1.0-SNAPSHOT.jar
2015-09-28 08:10:11.412  INFO 2386 --- [           main] o.apache.camel.spring.boot.FatJarRouter  : Starting FatJarRouter v2.15.3 on camelpi with PID 2386 (started by pi in /home/pi/deploy)
....
2015-09-28 08:11:23.385  INFO 2386 --- [           main] c.g.c.i.c.gps.bu353.GpsBu353Component    : (Re)starting GPS daemon.

Do you think I should try to debug the component's code when running on the Pi to see what's happening? And by the way, I run this on a Raspberry Pi 1 Model B. The route is declared within a Camel Spring Boot application in a FatJarRouter.

[hekonsek]

Hi Thomas,

Can you give the component a chance to restart the GPS daemon? Also please don't start daemon by yourself (manually). Let the Camel handle all of this :) . Summarizing the steps:

a) restart RPi b) don't start GPSD by yourself c) start Camel app d) wait for a while (2-3 minutes) and give BU353 component a chance to properly start the GPSD

Can you try this?

Cheers!

pon., 28.09.2015 o 08:25 użytkownik thberger notifications@github.com napisał:

Hi, would be great I we can get the Bu353 to fly with camel. I just tried what you suggested, but now with the result that the component has problems to restart the daemon. Here is the output of what I did:

---> Disconnect the Bu353 from USB port pi@camelpi ~ $ sudo reboot now pi@camelpi ~ $ uname -a Linux camelpi 4.1.7+ #817 PREEMPT Sat Sep 19 15:25:36 BST 2015 armv6l GNU/Linux pi@camelpi ~ $ gpsd -V gpsd: 3.6 (revision 3.6) -------> Now I attach the Bu353 via USB pi@camelpi ~ $ lsusb | grep Prolific Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port pi@camelpi ~/deploy $ java -jar camel-gps-1.0-SNAPSHOT.jar 2015-09-28 08:10:11.412 INFO 2386 --- [ main] o.apache.camel.spring.boot.FatJarRouter : Starting FatJarRouter v2.15.3 on camelpi with PID 2386 (started by pi in /home/pi/deploy) .... 2015-09-28 08:11:23.385 INFO 2386 --- [ main] c.g.c.i.c.gps.bu353.GpsBu353Component : (Re)starting GPS daemon.

Do you thing I should try to debug the component's code when running on the Pi to see what's happening? And by the way, I run this on a Raspberry Pi 1 Model B. The route is declared within a Camel Spring Boot application in a FatJarRouter.

— Reply to this email directly or view it on GitHub https://github.com/rhiot/rhiot/issues/210#issuecomment-143651105.

Henryk Konsek http://about.me/hekonsek

[thberger]

Hi Henryk,

thanks for the quick response! Just to clarify: I invoked gpsd -V just to show you the version I use. I didn't start the daemon itself. I checked with

ps aux | grep gps

that really nothing related to gps is running before I start the Camel app. But I will wait for more minutes as you suggest and report back!

Cheers!

[thberger]

Hi,

I made some progress on the issue. While I still face the same problem on my RPi, I tried the code on my laptop with Ubuntu 14.04 and the Bu353 connected:

1. After a few retries, the component succeeds to start gpds and configure the device for NMEA mode. At least the code accepts the state, as one gpsctl call finally returns the expected string ("gpsctl:ERROR: /dev/ttyUSB0 mode change to NMEA failed") so that the while loop is left.
2. Then, the consumer has the same problem to poll the device as reported on my Rpi. The FileNotFoundException is thrown saying the device (/dev/ttyUSB0) is busy.
3. But after about 30 seconds and a bunch of failed access attempts, the file stream can finally be read, delivering a GPRMC sentence with my coordinates. This is parsed to the ClientGpsCoordinates object. Unfortunately, Camel now fails to write the messages to file:

org.apache.camel.component.file.GenericFileOperationFailedException: Cannot store file: /home/tommy/devel/gps-coordinates/ID-tommy-MBP-ubuntu-53539-1443479657112-0-1
    at org.apache.camel.component.file.FileOperations.storeFile(FileOperations.java:292)
    at org.apache.camel.component.file.GenericFileProducer.writeFile(GenericFileProducer.java:277)
    at org.apache.camel.component.file.GenericFileProducer.processExchange(GenericFileProducer.java:165)
    ...
Caused by: org.apache.camel.InvalidPayloadException: No body available of type: java.io.InputStream but has value: com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates@74b5dcd7 of type: com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates on: Message: com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates@74b5dcd7. Caused by: No type converter available to convert from type: com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates to the required type: java.io.InputStream with value com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates@74b5dcd7. Exchange[Message: com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates@74b5dcd7]. Caused by: [org.apache.camel.NoTypeConversionAvailableException - No type converter available to convert from type: com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates to the required type: java.io.InputStream with value com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates@74b5dcd7]
    at org.apache.camel.impl.MessageSupport.getMandatoryBody(MessageSupport.java:101)
    at org.apache.camel.component.file.FileOperations.storeFile(FileOperations.java:273)
    ... 21 common frames omitted
Caused by: org.apache.camel.NoTypeConversionAvailableException: No type converter available to convert from type: com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates to the required type: java.io.InputStream with value com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates@74b5dcd7
    at org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:177)
    at org.apache.camel.impl.MessageSupport.getMandatoryBody(MessageSupport.java:99)
    ... 22 common frames omitted

My route is configured as follows:

from("gps-bu353:current-position").
  to("file:////home/tommy/devel/gps-coordinates");

But I still wonder why the component tries to read from the device directly (/dev/ttyUSB0). As I understood gpsd, a direct read is not required as the gpsd provides the data via its local port (2947 by default). In fact, I though the main purpose of gpsd is to read from the device and multiplex the data to multiple clients by making the data available through the port? See also http://www.catb.org/gpsd/client-howto.html.

Cheers

[levackt]

Great feedback thanks, I also think we should consider connecting to 2947 or some specified port as < 3000 may be restricted, and watching for gps events of interesting types. I wonder if we can/should use gpsd4java[1]? Will do some testing with it and see how/if it works, hasn't been maintained recently.

Usually when I get this particular error, I also can't get data from the device using gpsmon/cgps, and a bandaid solution that works most of the time is "chmod a+rw /dev/ttyUSB0". I found a couple of places such as [2] and [3] that suggest to add it to the "/lib/udev/gpsd.hotplug" file but that didn't work for me, worth a try and hopefully you have better luck.

Also tail /var/log/syslog or check some other way if your device is really assigned /dev/ttyUSB0, by default when the device is unplugged and reconnected, even to the same physical usb port, it can be assigned to /dev/ttyUSB1/2 instead. This isn't specifically a Rhiot issue but if we stick with ttyUSB0 we should document how to configure udev rules for the BU 353 for robustness.

PS Henryk, can we see your "/etc/default/gpsd" please?

[1] https://github.com/taimos/GPSd4Java [2] https://www.raspberrypi.org/forums/viewtopic.php?p=90223 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697664

On Tue, Sep 29, 2015 at 1:05 AM, thberger notifications@github.com wrote:

Hi,

I made some progress on the issue. While I still face the same problem on my RPi, I tried the code on my laptop with Ubuntu 14.04 and the Bu353 connected:

1.

After a few retries, the component succeeds to start gpds and configure the device for NMEA mode. At least the code accepts the state, as one gpsctl call finally returns the expected string ("gpsctl:ERROR: /dev/ttyUSB0 mode change to NMEA failed") so that the while loop is left. 2.

Then, the consumer has the same problem to poll the device as reported on my Rpi. The FileNotFoundException is thrown saying the device (/dev/ttyUSB0) is busy. 3.

But after about 30 seconds and a bunch of failed access attempts, the file stream can finally be read, delivering a GPRMC sentence with my coordinates. This is parsed to the ClientGpsCoordinates object. Unfortunately, Camel now fails to write the messages to file:

org.apache.camel.component.file.GenericFileOperationFailedException: Cannot store file: /home/tommy/devel/gps-coordinates/ID-tommy-MBP-ubuntu-53539-1443479657112-0-1 at org.apache.camel.component.file.FileOperations.storeFile(FileOperations.java:292) at org.apache.camel.component.file.GenericFileProducer.writeFile(GenericFileProducer.java:277) at org.apache.camel.component.file.GenericFileProducer.processExchange(GenericFileProducer.java:165) ... Caused by: org.apache.camel.InvalidPayloadException: No body available of type: java.io.InputStream but has value: com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates@74b5dcd7 of type: com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates on: Message: com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates@74b5dcd7. Caused by: No type converter available to convert from type: com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates to the required type: java.io.InputStream with value com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates@74b5dcd7. Exchange[Message: com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates@74b5dcd7]. Caused by: [org.apache.camel.NoTypeConversionAvailableException - No type converter available to convert from type: com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates to the required type: java.io.InputStream with value com.github.camellabs.iot.component.gps.bu353.ClientGpsCoor dinates@74b5dcd7] at org.apache.camel.impl.MessageSupport.getMandatoryBody(MessageSupport.java:101) at org.apache.camel.component.file.FileOperations.storeFile(FileOperations.java:273) ... 21 common frames omitted Caused by: org.apache.camel.NoTypeConversionAvailableException: No type converter available to convert from type: com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates to the required type: java.io.InputStream with value com.github.camellabs.iot.component.gps.bu353.ClientGpsCoordinates@74b5dcd7 at org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:177) at org.apache.camel.impl.MessageSupport.getMandatoryBody(MessageSupport.java:99) ... 22 common frames omitted

My route is configures as follows:

from("gps-bu353:current-position"). to("file:////home/tommy/devel/gps-coordinates");

But I still wonder why the component tries to read from the device directly (/dev/ttyUSB0). As I understood gpsd, a direct read is not be required as the gpsd provides the data via its local port (2947 by default). In fact, I though this is the main purpose of gpsd to read from the device and multiplex the data to multiple clients by making the data available through the port? See also http://www.catb.org/gpsd/client-howto.html.

Cheers

— Reply to this email directly or view it on GitHub https://github.com/rhiot/rhiot/issues/210#issuecomment-143897798.

[hekonsek]

Hi guys,

@thberger Yay, cool to see that you managed to read the data from the GPS! At least on the desktop. Actually it also takes few failed attempts to on RPi get property start GPSD daemon, so this is normal for the current version of the GPSD I guess.

You can't write ClientGpsCoordinates directly to the file. You have to serialize it before, like that [1]. We can also consider adding Camel type converter between String <=> ClientGpsCoordinates that would call this [2] method under the hood. Any volunteers for #212? :)

I decided to read to from the /dev/ttyUSB0 as it was looking as the simplest solution for me, but probably reading from GPSD daemon would be the batter idea, as it may be more reliable.

@thberger @levackt Maybe we can try to switch to GPSd4Java as @levackt and use it to read the GPS data? Anybody would like to give it a try?

PS My /etc/default/gpsd is default one.

Many thanks for all your researches! I really appreciate it.

[1] https://github.com/rhiot/rhiot/blob/master/gateway/src/main/groovy/io/rhiot/gateway/gps/GpsBu353Verticle.groovy [2] https://github.com/rhiot/rhiot/blob/master/iot/components/camel-gps-bu353/src/main/java/io/rhiot/component/gps/bu353/ClientGpsCoordinates.java#L63

[hekonsek]

In general I'd love to refactor BU353 connectivity if only that would result in the better reliability on your Rpi boxes. If you guys could check if GPSd4Java connects properly to the GPSD on your machines, then we could start the refactoring.

Thanks again!

[levackt]

You're right about the patience with gpsd, it works great after I removed, purged and reinstalled gpsd, just wait a few minutes sometimes. I added none of the chmod and other hacks as the errors in syslog don't affect the performance of the device.

Also happy to report that gpds4java works from my computer no problem, when rhiot or cgps don't work on the Pi then of course it doesn't work either. I'll keep working on it as it offers a few more advantages.

I have the type converter working already, PR inbound.

On Tue, Sep 29, 2015 at 2:01 PM, Henryk Konsek notifications@github.com wrote:

In general I'd love to refactor BU353 connectivity if only that would result in the better reliability on your Rpi boxes. If you guys could check if GPSd4Java connects properly to the GPSD on your machines, then we could start the refactoring.

Thanks again!

— Reply to this email directly or view it on GitHub https://github.com/rhiot/rhiot/issues/210#issuecomment-144038057.

[levackt]

A gpsd component is developing in this branch, it's based on gpsd4java as discussed. A couple of notes if you want to try it, or change the direction it's going.

1. I assume you have a running gpsd on the host, so there's no attempt to stop/start gpsd, only subscribe and unsubscribe, by default to localhost:2947 Need to consider how to ensure gpsd is installed, especially with remote, for now I'll modify the existing bu353 component to check the installation but I don't know how best to handle that with this component, besides perhaps checking on startup if the component is enabled to start immediately and can connect, open to ideas.
2. there are endpoint params so you can subscribe to multiple devices, mind that you first have to listen on all interfaces, ie start gpsd with -G
3. it's a whole new component to keep it tidy for now, although it has a dependency on gps-bu353 to use the ClientGpsCoordinates object, will fix it in the final form if it goes forward.
4. Only the ClientGpsCoordinates is supported with the original TPVObject (Time-Position-Velocity) available in the exchange header, I'm considering adding endpoint params to register interest only if over certain distance threshold, let me know if that makes sense as gpsd4java supports it and the param will allow me to hide the api. eg "gpsd:position?distance=1" will only consume when over 1km, miles is not supported but we can add conversion. I want to avoid registering gpsd4java listeners and any other api if possible, although that has some pros so I'm still open to it.

It's a drop-in replacement for gps-bu353 so if you're keen enough to clone, checkout and build, then you'd just replace your gps-bu353 endpoint with gpsd, and enable the verticle with camellabs_iot_gateway_gpsd=true Optionally pass host and port.

[hekonsek]

Hi Taariq,

Many thanks for this! I've been sick for the last two days. Now I'm going to the family trip - I will be back after Monday. I will look at your branch then. Many thanks again, it looks awesome! I really appreciate it.

Cheers!

[levackt]

All good hey, it's a big pleasure to help out a little and learn a lot, so it's me who's thankful. Take your time to get 100% strength back and enjoy the family, see you around next week.

On 02 Oct 2015, at 22:43, Henryk Konsek notifications@github.com wrote:

Hi Taariq,

Many thanks for this! I've been sick for the last two days. Now I'm going to the family trip - I will be back after Monday. I will look at your branch then. Many thanks again, it looks awesome! I really appreciate it.

Cheers!

— Reply to this email directly or view it on GitHub.

[thberger]

Hi,

many thanks for your help and support! Great news with the converter and gpsd4java based approach. I'll test Taariq's Camel GPS component from the branch this weekend on my Rpi and PC.

Best

[levackt]

Thanks Thomas, and apologies if you already took a look and didn't get it working, I just noticed I committed and didn't push it. :( Anyway I just pushed the distance listener stuff and instead of adding a listener for speed I modified the test to print different messages based on speed, using the Pojo from the header for now. Happy coding.

On Sat, Oct 3, 2015 at 9:47 AM, thberger notifications@github.com wrote:

Hi,

many thanks for your help and support! Great news with the converter and gpsd4java based approach. I'll test Taariq's Camel GPS component from the branch this weekend on my Rpi and PC.

Best

— Reply to this email directly or view it on GitHub https://github.com/rhiot/rhiot/issues/210#issuecomment-145212252.

[hekonsek]

Hi,

I believe that since GPSD can handle multiple GPS receivers, we should prefer it over /dev/tty* reading. Actually I'd like to add Taariq's camel-gpsd component to the project and deprecate my very own BU353 component.

@levackt I have granted you committer rights to the project. Can you start adding the camel-gpsd component to our codebase? I'd love to work with you on the new component from that point.

Great job! I love the new generic GPSD stuff.

Cheers!

[hekonsek]

Let's start with merging the code to the project. Then let's test it against our devices. After this it would be great to give it a try with some other GPS units - we could create the list of the supported GPS units. Awesome!

[levackt]

Nice one Henryk, I'll get on it, will add some more tests and polish with your guidance. Thanks for the warm welcome :)

On 06 Oct 2015, at 17:29, Henryk Konsek notifications@github.com wrote:

Hi,

I believe that since GPSD can handle multiple GPS receivers, we should prefer it over /dev/tty* reading. Actually I'd like to add Taariq's camel-gpsd component to the project and deprecate my very own BU353 component.

@levackt I have granted you committer rights to the project. Can you start adding the camel-gpsd component to our codebase? I'd love to work with you on the new component from that point.

Great job! I love the new generic GPSD stuff.

Cheers!

— Reply to this email directly or view it on GitHub.

[levackt]

Initial commit/push is to the new branch, hope that's where you need it for now, https://github.com/rhiot/rhiot/tree/feature/gpsd4java

Still a couple of todos so it feels like the branch is the right place, my remaining concerns are mainly in the GpsdConsumer and centred around the message payload, I think I mentioned them all previously and also left some notes in the code and docs.

Something else I'm considering is to modify the endpoint to take some additional params to pass to gpsd for things like port and which interface to listen on when starting a local process, for now even if we provide a ProcessManager we can't control things like which device, actually first prize if we can detect this as we still rely on "/dev/ttyUSB0". But it might just be nice to have.

I'll give it some more thought before circling back, please let me know if you guys have some concerns or wishlists too. Cheers

On Tue, Oct 6, 2015 at 6:39 PM, Taariq Levack taariql@gmail.com wrote:

Nice one Henryk, I'll get on it, will add some more tests and polish with your guidance. Thanks for the warm welcome :)

On 06 Oct 2015, at 17:29, Henryk Konsek notifications@github.com wrote:

Hi,

I believe that since GPSD can handle multiple GPS receivers, we should prefer it over /dev/tty* reading. Actually I'd like to add Taariq's camel-gpsd component to the project and deprecate my very own BU353 component.

@levackt https://github.com/levackt I have granted you committer rights to the project. Can you start adding the camel-gpsd component to our codebase? I'd love to work with you on the new component from that point.

Great job! I love the new generic GPSD stuff.

Cheers!

— Reply to this email directly or view it on GitHub https://github.com/rhiot/rhiot/issues/210#issuecomment-145901587.

[hekonsek]

Hi Taariq,

Is your current feature branch usable? If so, then feel free to merge it into the master even if it is not perfect yet. I will build it, test it on my RPi and help you polish the code.

Cheers!

[levackt]

Ok cool, yes it's useable and breaks nothing, Travis also passed earlier. If you don't have a Pi running then the simple GpsdComponentTest can take a while to fail. Now merged with master, new build is underway...

On Wed, Oct 7, 2015 at 4:28 PM, Henryk Konsek notifications@github.com wrote:

Hi Taariq,

Is your current feature branch usable? If so, then feel free to merge it into the master even if it is not perfect yet. I will build it, test it on my RPi and help you polish the code.

Cheers!

— Reply to this email directly or view it on GitHub https://github.com/rhiot/rhiot/issues/210#issuecomment-146210865.

[levackt]

Still todo in GpsdConsumer, decide what goes into the exchange and whether it goes into the header or property, currently there's the TPVObject. Along with that payload I added the host and port as headers but that can be confusing/unnecessary, keep in mind that it's lost when writing to file and back as we don't store it in ClientGpsCoordinates.

[hekonsek]

I would remove host and port from the headers. In general we try not to copy information from endpoint to exchange, as user can do it by him/herself.

I like your approach with the payload. That is we use our ClientGpsCoordinates as the body (as it is easy small and easy to serialize and deserialize), while we keep the original TPVObject in the header, if user needs more detailed information. I would keep it as it is.

[hekonsek]

Cool! I will try to run the component against my RPi today or tomorrow. Many thanks again for all your work Taariq!

[levackt]

Cool, removed the headers. I also fixed the integration test to use some remote Pi's address like rhiot-pi, you can change that, my own Pi is typically rhiot-pi.local, point is that the integration test shouldn't use localhost and try to start gpsd daemon.

[levackt]

Also made it explicit that it's the TPVObject and not the marker interface, in the scope of the Rhiot this should be good, can always widen it later but I have doubts. Thanks for the polish, looking better already :)

[levackt]

Just remembered we can use the nifty Pi detector to find the remote pi for the integ test, will fix that tomorrow too.

On 07 Oct 2015, at 17:26, Henryk Konsek notifications@github.com wrote:

Cool! I will try to run the component against my RPi today or tomorrow. Many thanks again for all your work Taariq!

— Reply to this email directly or view it on GitHub.

[thberger]

Hi guys,

just a quick update from my side: As promised, I tested Taariq's GPS component from the branch. It worked very well on my Raspberry Pi! So I really appreciate a merge of this version into master. Will make some more tests in the next days. Thanks a lot!

[levackt]

Nice one, so glad it works on your Pi. And thanks to you too.

On 07 Oct 2015, at 23:16, thberger notifications@github.com wrote:

Hi guys,

just a quick update from my side: As promised, I tested Taariq's GPS component from the branch. It worked very well on my Raspberry Pi! So I really appreciate a merge of this version into master. Will make some more tests in the next days. Thanks a lot!

— Reply to this email directly or view it on GitHub.

[hekonsek]

It is good to see that component works on many devices. I will give it a try tomorrow as well and continue to perform the peer review.

Thanks guys!

[hekonsek]

So I have officially deprecated BU353 component (#232). Long live the GPSD component. That should save us from the dreadful "device or resource busy" errors. Closing this one then. Thank you guys for working on this stuff!