/dev/ttyUSB0 changes to /dev/ttyUSB1

[Jonathan Ryshpan]

Occasionally the port on which the Davis VPro2 console is visible changes from /dev/ttyUSB0 to /dev/ttyUSB1.  I haven't noticed any reason for this, in particular no change in physical connections; it just happens when it happens.  When it does happen, the server won't start since it's looking for the console on the wrong port.

Has anyone else noticed this?  Any idea what's happening?

Thanks - jon

[Fernando E. Ochera Bagán]

Hi,
Please search the list archives. This problem has appeared several times.
(You can make udev to restart wview on every usb change).
Regards,
Fernando

2012/5/17 Jonathan Ryshpan <jon...@pacbell.net>:

> --
> You received this message because you are subscribed to the Google Groups
> "wview" group.
> To post to this group, send email to wv...@googlegroups.com.
> To unsubscribe from this group, send email to
> wview+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/wview?hl=en.



--
Fernando E. Ochera
fero...@gmail.com

[Alan]

IMHO, the best thing to do is to use a device name that's tied to the serial port that you want to use.  If you check inside of /dev/serial/by-id, you should see your serial ports listed with a more descriptive name.  This name will not change if the devices are discovered in a different order at boot time (or due to hot-plugging).

For example, my system has 3 USB-serial ports (actually, 2 RS-232 and 1 RS-422).  Here's the contents of that directory:

root@zbox:/etc/rsyslog.d# ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Apr 27 16:58 usb-FTDI_FT232R_USB_UART_A80077TZ-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 May 14 20:33 usb-FTDI_USB_FAST_SERIAL_ADAPTER_FT41IPQR-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 May 14 20:33 usb-FTDI_USB_FAST_SERIAL_ADAPTER_FT41IPQR-if01-port0 -> ../../ttyUSB1

The port that I want to use is ttyUSB0 (right now anway), so in the wview "Station Device" field, I put in:

/dev/serial/by-id/usb-FTDI_USB_FAST_SERIAL_ADAPTER_FT41IPQR-if00-port0

That should take care of your issue.  Hope this helps!

[Jonathan Ryshpan]

This looks like the "right way" (tm) to handle the problem.

Thanks - jon

[Jeff]

http://groups.google.com/group/wview/browse_thread/thread/c2213f94704f37b6/68d41d34d3555678?lnk=gst&q=udev#68d41d34d3555678

[Fabio Muzzi]

> /dev/serial/by-id/usb-FTDI_USB_FAST_SERIAL_ADAPTER_FT41IPQR-if00-port0

This method (or a similar method where I use a symlink that
dinamically changes when the usb port changes) does not seem to work
unless you restart vwiev after the usb disconnection and reconnection.

[Jonathan Ryshpan]

Just so (8-(, unfortunately.

jon

[Fabio Muzzi]

The only working method is to use a true serial interface, it seems.

Fabio IZ4UFQ

[Jonathan Ryshpan]

The link that Jeff gives ends with a troublesome posting, which I have
just discovered for myself; and there is more bad news from Fabio Muzzi:

> On Apr 9 2010, 5:37am Graham Eddy wrote:
> Wview has the old /dev/vpro device file open when /dev/vpro file is
> re-created (by various re-plugging of USB devices) so does not pick
> up the new config automatically. the only way at present for wview to
> pick up the new /dev/vpro is to restart wview. one *could* add a rule
> ACTION="add",RUN+="/etc/init.d/wview restart",
> but this would be very messy after a reboot (too early)
>
> Maybe we could ask for a wview enhancement to accept a gentle poke to
> re-open the device file? then have a rule like:
> ACTION="add",RUN+="/usr/local/bin/wview_reopen_port"
> where the client can just die quietly if wview not running or not yet
> opened the device file on startup

On Mon, 2012-06-04 at 12:12 -0700, Fabio Muzzi wrote:
> The only working method is to use a true serial interface, it seems.

Has anyone come up with a good method for getting wview restarted when
the USB port changes its name? Or is Fabio correct?

On Thu, 2012-05-17 at 14:53 -0700, Jeff wrote:
> http://groups.google.com/group/wview/browse_thread/thread/c2213f94704f37b6/68d41d34d3555678?lnk=gst&q=udev#68d41d34d3555678
>
> On May 17, 5:11 pm, Jonathan Ryshpan <jonr...@pacbell.net> wrote:
> > This looks like the "right way" (tm) to handle the problem.
> >
> >

[Sir Geek]

Have a script that runs as part of the startup that creates a link to the correct device name ?

Have you looked in your OS's docs (or posted to that group's forums) about the device changing names ?

The only time I've seen that happen in Fedora is with the Software Raid and only when you do a "safe" start.  I reboot and its fine again on the next startup..

[Jonathan Ryshpan]

On Mon, 2012-06-04 at 16:05 -0400, Sir Geek wrote:
> Have a script that runs as part of the startup that creates a link to
> the correct device name?

I've already done the equivalent: using an entry in /dev/serial/by-id/,
which always points to the correct device. However when /dev/ttyUSB0
changes to /dev/ttyUSB1, wview has to be restarted. My hope is to run
wview in a server that can operate unattended for long periods of time.

> Have you looked in your OS's docs (or posted to that group's forums)
> about the device changing names ?

It's a bad idea to post to two lists at the same time. I'm waiting to
see if anything interesting turns up in this list in the next day or so.

> The only time I've seen that happen in Fedora is with the Software
> Raid and only when you do a "safe" start. I reboot and its fine again
> on the next startup..

You're a lucky person.

[Fabio Muzzi]

> > Maybe we could ask for a wview enhancement to accept a gentle poke to
> > re-open the device file?  then have a rule like:
> >         ACTION="add",RUN+="/usr/local/bin/wview_reopen_port"
> > where the client can just die quietly if wview not running or not yet
> > opened the device file on startup

This is a good idea. The issue is that Wview does keep the serial open
all time, which is fine unless the serial dies and restarts with a
different file handler. (even with the same device name).

We need to make wviev close and reopen the serial device, and having a
way of telling it to do so, without doing a complete restart, is the
only way to go, I suppose. Be it a dedicated command, or some kill
signal, that is the right way to do it.

Unless, of course, you happen to have a USB serial that does not reset
itself from time to time, or a true serial port.


Fabio IZ4UFQ