Hi Paul,

I have another one:

Elabnet (PBM01)  -- 0403:6015 -- with UNIQUE product and manufacture ID

Sorry for the delay. I'm still negotiating a sample for your.

Thanks
Dirk

Am 23.09.2014 um 23:27 schrieb Paul Alfille:
> 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)
> TAI603B -- 10c4:ea60 -- CP210x Unclear if it's generic or not
> 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.
>
> 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