Hello,
I agree, that the OWFS server should not start testing each and every
possibility of the system, to find, whether there are 1-Wire devices
connected.
To resolve this I suggest to implement something like
"sudo service owserver autodetect"
By this method the user knows, that OWFS is trying to check every 1Wire
possibility.
Following this autodetect procedere there should be a report of the
findings "somewhere", e.g. in owfs_autodetect.txt
Results could be something like
; OWFS version xx.yy autodetect results from 13:25 at dd.mm.yyyy
;
; suggested setup to be included in the default configuration file
(/etc/owfs.conf)
...
# Serial port: DS9097
server: device = /dev/ttyUSB0
...
; end autodetect
If you do it this way, the make of the USB device would be not critical.
Just use brute force, try all serial line you find, and wait for the
"right" response. If you have a USB-RS232 converter somewhere in the path,
you may not even get all information, and still get a good response.
Thanks for the reference to the "feature request" possibility on
Sourceforge.
I am still researching, what is already implemented in OWFS. So my list may
melt down, once I found all the information I am looking for, ;-) .
Best regards
Ekkehard
2014-09-24 8:49 GMT+02:00 Johan Ström <jo...@stromnet.se>:
> From the article, it sounds like " udevadm info -a -p
> /sys/bus/usb-serial/devices/ttyUSB0/" might be interesting (if it returns
> the relevant info)?
>
> Did some digging on FreeBSD, seems it's possible to find the associated
> TTY from sysctl:
>
> sysctl -a|grep "^dev\.uftdi"
> dev.uftdi.2.%desc: FT232R USB UART
> dev.uftdi.2.%driver: uftdi
> dev.uftdi.2.%location: bus=2 hubaddr=2 port=1 devaddr=3 interface=0
> dev.uftdi.2.%pnpinfo: vendor=0x0403 product=0x6001 devclass=0x00
> devsubclass=0x00 sernum="AAAAAAxXXXX" release=0x0600 mode=host
> intclass=0xff intsubclass=0xff intprotocol=0xff ttyname=U0 ttyports=1
> dev.uftdi.2.%parent: uhub3
> dev.uftdi.2.ttyname: U0
> dev.uftdi.2.ttyports: 1
>
> This is present as /dev/cuaU0 (ttyname). It's pretty trivial to iterate
> the sysctl MIB tree using sysctl() calls, so looking for the dev.uftdi
> devices (or others, if other lowlevel special impls are written) should be
> doable.
>
>
> On 24/09/14 02:53, David Torrey wrote:
>
> Does this help? Seems to be a lot more complicated than it should be, but
> at least it’s fairly deterministic.
>
>
> http://askubuntu.com/questions/184526/how-to-get-bus-and-device-relationship-for-a-dev-ttyusb
>
> Dave
>
> On Sep 23, 2014, at 7:58 PM, Paul Alfille <paul.alfi...@gmail.com> wrote:
>
> Ok, I'm perplexed!
>
> I need help mapping device name (e.g. /dev/ttyUSB0) to USB bus:devnum
> that I get in libusb.
>
> I can probably do it by parsing 'dmesg' but that's rather inelegant.
> Perhaps the data is somewhere in /sys or /proc?
>
> The problem is that after searching (and perhaps tuning) USB devices, I
> then need to use them as a serial device.
> I need to go in both directions -- both to not open use a bus master twice
> and to check device names.
>
> Paul
>
> On Tue, Sep 23, 2014 at 5:37 PM, Dirk Opfer <d...@do13.de> wrote:
>
>> 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> 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> 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
>>>> 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
>>> Analyzerhttp://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>>
>>>
>>>
>>> _______________________________________________
>>> Owfs-developers mailing
>>> listOwfs-developers@lists.sourceforge.nethttps://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
>> Analyzerhttp://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>
>>
>>
>> _______________________________________________
>> Owfs-developers mailing
>> listOwfs-developers@lists.sourceforge.nethttps://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
>
>
>
>
> ------------------------------------------------------------------------------
> 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
> Analyzerhttp://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Owfs-developers mailing
> listOwfs-developers@lists.sourceforge.nethttps://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
