On 9/23/14 23:27 , Paul Alfille wrote:
Ok, I did some testing of various USB 1-wire bus masters:

LinkUSB -- 0403:6001 -- FTDI but no identifying charcteristics (Except serial number, but that's probably not consecutive)
Yeah, standard FTDI vid/pid. Identical to both my LinkUSB and a random FTDI-based serial adapter. I never got any response from iButtonLink regarding their serial numbers, so unknown.
TAI603B -- 10c4:ea60 -- CP210x Unclear if it's generic or not
CP210x is another serial adapter chip. My AEON Labs Z-Wave adapter has the exact same VID/PID ("CP2102 USB to UART Bridge Controller").
USB9097 --1a86:7523 -- HL-340 Seems generic
ECLO -- 0403:ea90 -- FTDI with UNIQUE product ID
MasterHub -- 04d8:f897 -- MTI with UNIQUE product ID
DS9490R -- 04fa:2490 -- Maxim with UNIQUE ID

So it looks like only ECLO, the new Hobby Boards MasterHub, and the DS9490R can be auto-detected by USB scanning. I had high hopes for the LinkUSB, but perhaps I have an early version and the internal fields have changed.
Indeed, those should be fully possible to auto-detect. Any FTDI-based with the default pid is probably out of the question though (i.e. LinkUSB. I have a v1.5).
So, how do we address the others?

Paul Alfille




On Tue, Sep 23, 2014 at 3:40 PM, Johan Ström <jo...@stromnet.se <mailto:jo...@stromnet.se>> wrote:

    I'm all for auto-detection, when it is possible to do so reliably.
    As you mentioned in the other reply, randomly poking at stuff is
    neither reliable or safe..
    So, the question is what we can do to make it as smooth for the
    user as possible..

    A possibly a new approach, with OS-specific resolving you mentioned:

    If user specifies --link /dev/ttyS0, -d /dev/ttyS0 or other, we
    could try OS-specific lookups to find what serial hardware it is
    using. For example, if we can find out that it is a FTDI based
    device, we could try to use ft_ftdi instead of ft_serial. If we
    cannot find out, we just fall back to regular TTY access.

    If user specifies --link 2:3, -d 3:4, --link usb:NNSERIAL or
    such,  we look for that specific USB device. If it is a FTDI
    device, we use ft_ftdi. Else, we can either fail, or for
    device-types which are serial, we could try to reverse-lookup TTY
    using OS-specific approach.

    Note: on FreeBSD there are separate /dev permissions for accessing
    the TTY and the USB device. Not sure if Linux has the same.

    Or, a more intrusive approach, clean up all parameters and go a
    generic device-option: --device <type>[ <port-or-address>].
    Examples:
    --device link /dev/ttyS0 (would also possibly try to use OS
    specific resolving)
    --device link usb:3:4
    --device link usb:NNSERIAL
    --device ds9097 /dev/ttyS0
    --device ds9097 usb:3:4
    --device ds9097 usb:NNSERIAL
    --device ds9097u /dev/ttyS0
    --device i2c /dev/i2c-0
    --device masterhub /dev/ttyS0
    --device usb                   (this would search for DS9490R or
    PuceBaboon or any other USb which we can *reliably* identify)

    What would your optimal owfs usage model look like?


    For the record, here are the usbconfig --dump_device_desc data for
    my two FTDI devices:

    ugen1.3: <FT232R USB UART FTDI> at usbus1, cfg=0 md=HOST spd=FULL
    (12Mbps) pwr=ON (90mA)
      bLength = 0x0012
      bDescriptorType = 0x0001
      bcdUSB = 0x0200
      bDeviceClass = 0x0000
      bDeviceSubClass = 0x0000
      bDeviceProtocol = 0x0000
      bMaxPacketSize0 = 0x0008
      idVendor = 0x0403
      idProduct = 0x6001
      bcdDevice = 0x0600
      iManufacturer = 0x0001  <FTDI>
      iProduct = 0x0002  <FT232R USB UART>
      iSerialNumber = 0x0003  <A9xxxxxD>
      bNumConfigurations = 0x0001

    ugen2.3: <USB FAST SERIAL ADAPTER FTDI> at usbus2, cfg=0 md=HOST
    spd=FULL (12Mbps) pwr=ON (44mA)
      bcdUSB = 0x0110
      bcdDevice = 0x0400
      iManufacturer = 0x0001  <FTDI>
      iProduct = 0x0002  <USB FAST SERIAL ADAPTER>
      iSerialNumber = 0x0003  <FTCDXXX>
    (skipped all other attributes which are identical)



    Johan


    On 9/22/14 18:23 , Paul Alfille wrote:
    I notice in recent Linux (Fedora specifically) that USB devices
    get pretty consistently listed by a reasonably consistent and
    recognizable name in /dev/serial/by_id.

    I haven't looked to closely at all the USB fields yet, but some
    devices have unique identifiers rather than the generic
    USB/serial. I was hoping to scan for known patterns, apply any
    optimizations, and then connect. The upcoming USB HobbyBoards hub
    will have that.

    My dream is that owfs will be as "automatic" as possible.
    Currently we can automatically scan for:
    i2c
    DS9490R
    HA7Net
    OWSERVER-ENET
    w1

    Hardware serial will always be a problem, but some USB-serial
    might be possible.

    Paul

    On Mon, Sep 22, 2014 at 2:59 AM, Johan Ström <jo...@stromnet.se
    <mailto:jo...@stromnet.se>> wrote:


        On 22/09/14 00:21, Robin Gilks wrote:
        >> 1. Trying to resolve a serial port TTY name (i.e.
        /dev/cuaU1 on FreeBSD)
        >> to a potential USB device is probably doable, but not
        without a lot of
        >> effort and OS specific code.
        >> I don't think it's worth trying to go down that road.
        >>
        > How about using udev on Linux (is there an equivalent on other OSes?) 
that
        > creates a symlink to a device node with a unique name from
        the type (FTDI)
        > and bus number and OWFS looks for that specific device name.
        >
        > Just an idea (had to do that years ago with serial devices
        to sort out a
        > connection to a weather station and an IR blaster, never
        sure what device
        > names each would come up with!).
        >
        >

        I have a similar setup myself, using FreeBSD's devd. It uses
        my known,
        hard-coded USB serials to set up a symlink from
        /dev/cua-linkusb to
        /dev/cuaXXX when device is detected, to easier find which tty
        device I
        should be using for what (I think I have ~4 serial ports on
        my box)

        However, this doesn't solve the auto-deteciton problem, the
        user still
        needs to manually tell which USB device to be used, by
        serial-no or
        otherwise. And if that has to be done, it could just as well
        be done
        directly in owfs.

        
------------------------------------------------------------------------------
        Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
        Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI
        DSS Reports
        Are you Audit-Ready for PCI DSS 3.0 Compliance? Download
        White paper
        Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog
        Analyzer
        
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
        _______________________________________________
        Owfs-developers mailing list
        Owfs-developers@lists.sourceforge.net
        <mailto:Owfs-developers@lists.sourceforge.net>
        https://lists.sourceforge.net/lists/listinfo/owfs-developers




    
------------------------------------------------------------------------------
    Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
    Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
    Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
    Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
    http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk


    _______________________________________________
    Owfs-developers mailing list
    Owfs-developers@lists.sourceforge.net  
<mailto:Owfs-developers@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/owfs-developers


    
------------------------------------------------------------------------------
    Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
    Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS
    Reports
    Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
    Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
    http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
    _______________________________________________
    Owfs-developers mailing list
    Owfs-developers@lists.sourceforge.net
    <mailto:Owfs-developers@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/owfs-developers




------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk


_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Reply via email to