I've had a long discussion about this on another list, and the consensus
is that to cure the problem the wview server will have to be rewritten
to recognize when there is a loss of service from the Davis console and
when this happens close and reopen the port, which will (of course) have
to be pointed to a fixed location as you have done.
I've been meaning to do some work on this but have been too lazy to do so.
Here's a summary of the discussion:
From: Jonathan Ryshpan <jonr...@pacbell.net>
To: Fedora List <us...@lists.fedoraproject.org>
Subject: /dev/ttyUSB0 spontaneously changes to /dev/ttyUSB1
Date: Tue, 05 Jun 2012 14:10:23 -0700
This is a problem which is being kicked around on another mailing list,
devoted to the wview weather server, without very good results, so I
have taken the liberty of putting it to a wider audience:
I have a system with a device (a Davis VantagePro2 weather console)
attached to a USB port. When the system starts, the device is visible
as /dev/ttyUSB0. A wview server attaches to /dev/ttyUSB0 and runs fine
till suddenly the device disappears from /dev/ttyUSB0 and appears
as /dev/ttyUSB1, at which time the server fails.
I suspect (though without much evidence) that the reason for the device
moving around is that there is a brief interruption of service from the
device, so that it appears to the computer that a *new* device has
appeared, which it has to find a device name for before it had deleted
the old name of the device.
I have tried the obvious, to open what ought to be the permanent
location of the device, namely:
But the software stops working when the change takes place, evidently
is a dynamically updated symbolic link to /dev/ttyUSB0 or /dev/ttyUSB1,
as the case may be. The server can only be made to work again by
Does anyone know of a way to keep the USB device open at a known
location, maybe by creating a permanent entry in /dev, and bypassing
udev? Any more theories about what, in general, is happening?
From: Sam Varshavchik <mr...@courier-mta.com>
Jonathan Ryshpan writes:
That strongly suggests that, even if the device reconnects under the same
name, your software app will still choke. If your app still chokes if it's
told to open /dev/serial/by-id, then it's going to have a problem when your
USB device disconnects and reconnects, even if it keeps the same /dev/ttyUSB?
name. You've just proven this yourself: by pointing your software to open
/dev/serial/by-id. After all, the device name now, as far as your software
is concerned, remains the same. The fact that the underlying symlink changes
is irrelevant; unless your software manually checks if it is opening a
symlink, then reads it and proceeds to use the real path. This seems very
So, your real problem is that your software is unable to handle the device
disconnecting and reconnecting. The different device name is a red herring.
Either the software needs to get fixed, so at least it can recover by
reopening the device (and you pointing it to the unchanged /dev/serial/by-id
path), or the underlying root cause of your USB device disconnect must be
identified, and fixed.
From: Tom Horsley <horsley1...@gmail.com>
On Tue, 05 Jun 2012 19:22:50 -0400
Sam Varshavchik wrote:
Libudev might help with this, and what the heck, it would probably
> Either the software needs to get fixed, so at least it can recover by
> reopening the device
be nice if the software could handle a user yanking out the device
as well (which would look much the same).
From: Chris Adams <cmad...@hiwaay.net>
Once upon a time, Jonathan Ryshpan <jonr...@pacbell.net> said:
I've had this happen on occasion (not often) with a GPS receiver used
for NTP. The reason the reconnected USB device gets a different
node/name is that your service is still connected to the old device
node, so it can't be reused.
Your service should notice that the serial device went away and exit.
I'm not sure if there's a way to have udev run a script or send a signal
when a device goes away.
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Jonathan Ryshpan wrote:
You need to fix the server.
> as /dev/ttyUSB0. A wview server attaches to /dev/ttyUSB0 and runs fine
> till suddenly the device disappears from /dev/ttyUSB0 and appears
> as /dev/ttyUSB1, at which time the server fails.
Jonathan Ryshpan wrote:
That sounds likely - dmesg will probably tell you.
> I suspect (though without much evidence) that the reason for the device
> moving around is that there is a brief interruption of service from the
> device, so that it appears to the computer that a *new* device has
> appeared, which it has to find a device name for before it had deleted
> the old name of the device.
Jonathan Ryshpan wrote:
Even if you overwrote the old device node the server needs to re-open the
> Does anyone know of a way to keep the USB device open at a known
> location, maybe by creating a permanent entry in /dev, and bypassing
> udev? Any more theories about what, in general, is happening?
file handle. Given the server will get notification that the port has
failed (eg a SIGHUP or going ready for read and getting an error on the
read) it shouldn't be too hard to fix it.