Thomas Oeding | 26 Jul 13:05 2014
Picon

Re: Owfs-developers Digest, Vol 98, Issue 10

Avahi was the tipp in the right direction:

# /opt/owfs/bin/owserver --i2c=/dev/i2c-1 -p 4304 --error_level=9
--foreground --nozero

works. Additional the Avahi-Daemon was not running. After starting it
the command

# /opt/owfs/bin/owserver --i2c=/dev/i2c-1 -p 4304 --error_level=9 --foreground

works too, without Segmentation fault!

 /opt/owfs/bin/owserver --i2c=/dev/i2c-1 -p 4304 --error_level=9 --foreground
  DEBUG: ow_daemon.c:(166) main thread id = 3070169616
  DEBUG: ow_avahi_link.c:(71) Avahi support: libavahi-client loaded successfully
  DEBUG: ow_avahi_link.c:(73) Avahi library function found: avahi_client_errno
  DEBUG: ow_avahi_link.c:(74) Avahi library function found: avahi_client_free
  DEBUG: ow_avahi_link.c:(75) Avahi library function found: avahi_client_new
  DEBUG: ow_avahi_link.c:(76) Avahi library function found:
avahi_client_get_domain_name
  DEBUG: ow_avahi_link.c:(77) Avahi library function found:
avahi_entry_group_add_service
  DEBUG: ow_avahi_link.c:(78) Avahi library function found:
avahi_entry_group_commit
  DEBUG: ow_avahi_link.c:(79) Avahi library function found:
avahi_entry_group_is_empty
  DEBUG: ow_avahi_link.c:(80) Avahi library function found:
avahi_entry_group_new
  DEBUG: ow_avahi_link.c:(81) Avahi library function found:
avahi_entry_group_reset
(Continue reading)

Thomas Oeding | 25 Jul 22:05 2014
Picon

Re: Owfs-developers Digest, Vol 98, Issue 10

Hello Paul,

here the output:

root <at> PiDoor:~# /opt/owfs/bin/owserver --fake=10 -p 4304
--error_level=9 --foreground
  DEBUG: ow_daemon.c:(166) main thread id = 3069538832
  DEBUG: ow_avahi_link.c:(71) Avahi support: libavahi-client loaded successfully
  DEBUG: ow_avahi_link.c:(73) Avahi library function found: avahi_client_errno
  DEBUG: ow_avahi_link.c:(74) Avahi library function found: avahi_client_free
  DEBUG: ow_avahi_link.c:(75) Avahi library function found: avahi_client_new
  DEBUG: ow_avahi_link.c:(76) Avahi library function found:
avahi_client_get_domain_name
  DEBUG: ow_avahi_link.c:(77) Avahi library function found:
avahi_entry_group_add_service
  DEBUG: ow_avahi_link.c:(78) Avahi library function found:
avahi_entry_group_commit
  DEBUG: ow_avahi_link.c:(79) Avahi library function found:
avahi_entry_group_is_empty
  DEBUG: ow_avahi_link.c:(80) Avahi library function found:
avahi_entry_group_new
  DEBUG: ow_avahi_link.c:(81) Avahi library function found:
avahi_entry_group_reset
  DEBUG: ow_avahi_link.c:(83) Avahi library function found:
avahi_service_resolver_free
  DEBUG: ow_avahi_link.c:(84) Avahi library function found:
avahi_service_resolver_new
  DEBUG: ow_avahi_link.c:(85) Avahi library function found:
avahi_service_browser_free
  DEBUG: ow_avahi_link.c:(86) Avahi library function found:
(Continue reading)

Thomas Oeding | 25 Jul 10:03 2014
Picon

DS2482-800 not working (Segmentation fault on Raspberry Pi)

Hello all,

i assembled an DS2482-800 (8 channel 1-wire i2c busmaster) on the
Adafruit Prototyping Pi Plate Kit
(http://www.adafruit.com/products/801) - i only connect 3.3V, GND,
SDA, SCL directly with the DS2482.
AD0,AD1,AD2 with GND
(http://datasheets.maximintegrated.com/en/ds/DS2482-800.pdf).

Software config:

Commentet out the blacklisting (because bcm2708 uses the GPIO pins):
----------------------------------
root <at> PiDoor:~# cat /etc/modprobe.d/raspi-blacklist.conf
# blacklist spi and i2c by default (many users don't need them)

#blacklist spi-bcm2708
#blacklist i2c-bcm2708
----------------------------------

Many modules loaded, maybe i must blacklist some to make the DS2482-800 work?
----------------------------------
root <at> PiDoor:~# lsmod
Module                  Size  Used by
i2c_dev                 5277  0
snd_bcm2835            18169  0
snd_soc_pcm512x         8909  0
snd_soc_wm8804          7833  0
snd_soc_bcm2708_i2s     5486  0
regmap_mmio             2818  1 snd_soc_bcm2708_i2s
(Continue reading)

Gregg Levine | 22 Jul 08:54 2014
Picon

Wiring the DS2423

Hello!
According to an applications note concerning the part and one person's
efforts, the counter functions are supposed to work on it, when the
external input lines are indeed switched, probably indeed grounded.

Can someone independently confirm that? The application note is AN3845.

>From that perspective I was indeed able to confirm what I was doing
before, is indeed correct. However it bothers me that the software
originally written for everything else and well before Windows Seven
confirms it by simply complaining about no device when the switch is
open.

I want to confirm that the whole business works before handing the
connector a DS9097U-9 to my running Linux system. (Which I'll need to
have built everything for it first....)
-----
Gregg C Levine gregg.drwho8 <at> gmail.com
"This signature fought the Time Wars, time and again."

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
Stefano Miccoli | 12 Jul 15:47 2014

patches for the build system and .cvsignore files

Hi,

while porting owserver to OSX I found some minor problem with the build system.

Here enclosed some patches that I think may be of general utility.

These are the problems that the attached patches try to address.

0001: when swig is not installed, "./configure" still tries to buid the swig modules owpython, owperl,
owphp 
0002: 'make dist' includes in the distribution some files that are actually built at configure or make
time; 'make distclean' leaves behind some files that should be deleted.
0003: almost all Makefile.am have a 'clean-generic' rule that deletes "*~" and ".*~" paths. The correct
Makefile heuristics should be that "make clean" only deletes files created by "make". Deleting files
created outside the make system is dangerous, and IMHO should be avoided.
0004: there are a lot of .cvsignore files left behind form the CVS system while .gitignore files are not complete.

This last patch (0004) is most a matter of taste. I deleted the .cvsignore files and reorganized the
.gitiignore files. In my proposed layout there is a top-level .gitingore for general patterns, and a more
specific .gitignore in each module to cope with more specific ignore patterns.

Hope this patches are not too biased towards my programming habits... (if so don't hesitate to reject them).

Stefano

Attachment (0002-corrections-to-some-Makefile.am.patch): application/octet-stream, 6758 bytes
(Continue reading)

Colin Reese | 10 Jul 20:09 2014
Picon

Limited Simultaneous Conversions?

Hello,

After talking with iButtonLink, it was brought to my attention that without
additional power, it is possible to have unsuccessful simultaneous read if
too many sensors are on the network, due to current draw during the
conversion.

Using the TMEX API, I can perform a match ROM and then issue a conversion
command, and then come back later to read the converted value. This way I
can issue conversion commands for, say, 20 ROMs without waiting for
conversion more than once.

Is there an analogous feature in owfs, e.g. a 'simultaneous' with a
specified group of ROMs?

Thanks,
Colin
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Owfs-developers mailing list
Owfs-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Loren Amelang | 10 Jul 03:29 2014
Picon

Re: "t=-62" Errors? (Paul Alfille)

Paul,

> As I understand, you are using the w1 interface and Beaglebone Black, but
> I'm not sure what the bus-master is. A gpio pin?

I pretty much followed these:
<https://groups.google.com/forum/#!topic/beagleboard/YPgbKxd2mRU>
<https://groups.google.com/forum/#!topic/beagleboard/LF8Vd8i3MpM>
<https://groups.google.com/forum/#!msg/beagleboard/zQ039ckqp3E/xKs_mp-GQtMJ>

Except I ended up with a 10K resistor in parallel with the suggested 4.7K pullup, for 3197 ohms, before I
actually got real readings. 

The hardware connection for 1-Wire:
--> 8_11 is GPIO1_13 on schematic
-->     "name": "GPIO1_13",
-->     "gpio": 45,
        "mux": "gpmc_ad13",
        "eeprom": 29,
-->     "key": "P8_11",
P8-11 is on the heartbeat LED side connector, sixth pin from the ethernet end: 
[ ] <-- ethernet connector
      1   2
      3   4
      5   6
      7   8
      9  10
     11  12
    ... ...

> -62 is not familiar to me. How often does it happen, and does the system
> continue to work with occasional glitches or does it need reset? Note that
> w1 errors might be reported by the system (dmesg).

Looks like roughly once a day, and it goes right back to working. The owfs file gets read every five minutes by
a chron injector in Node-RED. 

Here are the recent events from my Node-RED output file: 
(I tried to work backwards from "uptime" to the dmesg events below to get the logged times - somehow I ended up
a stable 58 minutes off, but it does look like the dmesg events match the output file...)
---
Thu Jul 03 2014 22:20:02 GMT-0700 (PDT)
ff ff ff ff ff ff ff ff ff : crc=c9 NO
cd 01 4b 46 7f ff 03 10 4a t=-62
Fri Jul 04 2014 14:00:02 GMT-0700 (PDT)
ff ff ff ff ff ff ff ff ff : crc=c9 NO
c8 01 4b 46 7f ff 08 10 3f t=-62
Sat Jul 05 2014 17:35:02 GMT-0700 (PDT)
ff ff ff ff ff ff ff ff ff : crc=c9 NO
fd 01 4b 46 7f ff 03 10 b6 t=-62
Sat Jul 05 2014 20:25:02 GMT-0700 (PDT) = 7/5/2014 19:27:34 PM
ff ff ff ff ff ff ff ff ff : crc=c9 NO
ef 01 4b 46 7f ff 01 10 f5 t=-62
Mon Jul 07 2014 08:15:02 GMT-0700 (PDT)
ff ff ff ff ff ff ff ff ff : crc=c9 NO
86 01 4b 46 7f ff 0a 10 5e t=-62
  Mon Jul 07 2014 13:45:02 GMT-0700 (PDT)
  50 05 4b 46 7f ff 0c 10 1c : crc=1c YES
  50 05 4b 46 7f ff 0c 10 1c t=85000  <-- the only 85C report in this time period
Mon Jul 07 2014 21:30:02 GMT-0700 (PDT)
ff ff ff ff ff ff ff ff ff : crc=c9 NO
ec 01 4b 46 7f ff 04 10 cf t=-62
Tue Jul 08 2014 12:55:01 GMT-0700 (PDT)
ff ff ff ff ff ff ff ff ff : crc=c9 NO
bb 01 4b 46 7f ff 05 10 c6 t=-62
Wed Jul 09 2014 04:30:01 GMT-0700 (PDT) = 7/9/2014 3:32:45 AM
ff ff ff ff ff ff ff ff ff : crc=c9 NO
83 01 4b 46 7f ff 0d 10 66 t=-62
-----

$ dmesg |grep "w1"
[  185.216244] bone-capemgr bone_capemgr.9: part_number 'w1', version 'N/A'
[  185.216352] bone-capemgr bone_capemgr.9: slot #7: 'Override Board Name,00A0,Override Manuf,w1'
[  185.217476] bone-capemgr bone_capemgr.9: slot #7: Requesting part number/version based 'w1-00A0.dtbo
[  185.217498] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 'w1-00A0.dtbo' for
board-name 'Override Board Name', version '00A0'
[  185.219060] bone-capemgr bone_capemgr.9: slot #7: dtbo 'w1-00A0.dtbo' loaded; converting to live tree
[ 9323.285544] w1_slave_driver 28-000000884d88: 18S20 doesn't respond to CONVERT_TEMP. = 7/5/2014
19:27:34 PM
[138328.444927] w1_slave_driver 28-000000884d88: 18S20 doesn't respond to CONVERT_TEMP.
[155728.922350] w1_slave_driver 28-000000884d88: 18S20 doesn't respond to CONVERT_TEMP.
[186030.560605] w1_slave_driver 28-000000884d88: 18S20 doesn't respond to CONVERT_TEMP.
[241532.000358] w1_slave_driver 28-000000884d88: 18S20 doesn't respond to CONVERT_TEMP.
[297634.120407] w1_slave_driver 28-000000884d88: 18S20 doesn't respond to CONVERT_TEMP. = 7/9/2014
3:32:45 AM

As I said above, I tried to convert these to logged times, and they do seem to match, if I include the one 85C
event among them. 

Interesting that there is a second DS18B20 in parallel, and it shows no dmesg events. It is not being
automatically polled or logged by Node-RED, but it works if I manually query it so it must be actively read
by owfs. The two matched exactly when read by a different 5V bus system, but on the BBB the second one reads 3C
to 5C higher. Have not figured that out yet...  And the first one actually reads 2C higher than it should, so
the second one is 5C to 7C high! I'm hoping a proper 5V USB interface will fix this...  

Obviously the -62 errors are not a big problem for my actual project, but I'm just really curious how they
happen. I've never seen them in any other 1-wire system. 

> I have a BBB and can try to see if I get the same errors if you describe
> your setup a little more.

More details available if needed...

Loren

 

> On Sat, Jul 5, 2014 at 8:32 PM, Loren Amelang <loren <at> pacific.net> wrote:
> 
>> My problem with 12-bit reads degenerating to half-degree steps seems to
>> be hiding since I built a new system with Ubuntu 14.04. I've only seen a
>> few individual readings that looked "stuck" at the previous value since
>> then, never full days of half-degree steps.
>> 
>> But I still get two kinds of rare, occasional errors. There are the
>> expected 85C errors, and these:
>> ---
>> Thu Jul 03 2014 22:15:01 GMT-0700 (PDT)
>> cd 01 4b 46 7f ff 03 10 4a : crc=4a YES
>> cd 01 4b 46 7f ff 03 10 4a t=28812
>> Thu Jul 03 2014 22:20:02 GMT-0700 (PDT)
>> ff ff ff ff ff ff ff ff ff : crc=c9 NO
>> cd 01 4b 46 7f ff 03 10 4a t=-62

| Loren Amelang | loren <at> pacific.net |

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
ppanish | 9 Jul 15:55 2014

MAX31850 code modifications

For anyone who cares,

Attached is a new version of ow_1820.c with minor modifications to correct operation with the MAX31850
thermocouple sensor. I have checked operation with the device and this appears to function properly.

Paul Panish

Attachment (ow_1820.c): application/octet-stream, 44 KiB

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Owfs-developers mailing list
Owfs-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Daniel MacKay | 6 Jul 02:37 2014
Picon

Humidity sensors

Hey all!

Does anyone have a source for cheap 1-wire humidity sensors?

--
Daniel MacKay
Halifax, Nova Scotia, Canada

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
Loren Amelang | 6 Jul 02:32 2014
Picon

"t=-62" Errors?

My problem with 12-bit reads degenerating to half-degree steps seems to be hiding since I built a new system
with Ubuntu 14.04. I've only seen a few individual readings that looked "stuck" at the previous value
since then, never full days of half-degree steps. 

But I still get two kinds of rare, occasional errors. There are the expected 85C errors, and these:
---
Thu Jul 03 2014 22:15:01 GMT-0700 (PDT)
cd 01 4b 46 7f ff 03 10 4a : crc=4a YES
cd 01 4b 46 7f ff 03 10 4a t=28812
Thu Jul 03 2014 22:20:02 GMT-0700 (PDT)
ff ff ff ff ff ff ff ff ff : crc=c9 NO
cd 01 4b 46 7f ff 03 10 4a t=-62
Thu Jul 03 2014 22:25:02 GMT-0700 (PDT)
c9 01 4b 46 7f ff 07 10 64 : crc=64 YES
c9 01 4b 46 7f ff 07 10 64 t=28562
---
Fri Jul 04 2014 13:55:01 GMT-0700 (PDT)
c8 01 4b 46 7f ff 08 10 3f : crc=3f YES
c8 01 4b 46 7f ff 08 10 3f t=28500
Fri Jul 04 2014 14:00:02 GMT-0700 (PDT)
ff ff ff ff ff ff ff ff ff : crc=c9 NO
c8 01 4b 46 7f ff 08 10 3f t=-62
Fri Jul 04 2014 14:05:02 GMT-0700 (PDT)
cc 01 4b 46 7f ff 04 10 67 : crc=67 YES
cc 01 4b 46 7f ff 04 10 67 t=28750
---

I've never seen -62 errors before. All of them I've captured in detail match the above pattern, where the
first byte string is all 'ff', and the second byte string matches the previous valid temperature exactly. 

What could be happening there? If the "t=" value is being derived from the byte string to the left of it, it
should be the correct temperature. But it is always -62. 

Why are there two lines of bytes? Are they separate reads? 

 
Apparently there are supposed to be "statistics" somewhere, but I don't seem to have any. Here is all I find:
---
ubuntu <at> arm:/sys/devices/w1_bus_master1$ ls
28-0000008847d6  power      w1_master_add              w1_master_name     w1_master_remove       w1_master_slaves
28-000000884d88  subsystem  w1_master_attempts         w1_master_pointer  w1_master_search       w1_master_timeout
driver           uevent     w1_master_max_slave_count  w1_master_pullup   w1_master_slave_count
---

Maybe the w1 interface doesn't provide statistics? 

 
Am I missing some source of deeper documentation than the web site provides? 

Loren

| Loren Amelang | loren <at> pacific.net |

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
Johan Ström | 22 Jun 23:09 2014
Picon

Support for LinkUSB via libftdi

Hi,

I've previously mentioned my work on LinkUSB performance improvements 
[1], and my goal to write a libftdi based implementation. The 
client-timings are generally cut about 2.5 times, depending on 
operation. A temp sensor is read in ~50ms instead of ~123ms.

I now have some code which works fine, I'm running this with my LinkUSB 
1.5 on FreeBSD 9.2, performing temperature readings of 24 mixed 
temperature sensors, and 4 DS2406's. The temperature is read every 30 
seconds, and I (try to) scan for alarm ever 0.3 seconds. In other words, 
pretty heavy load. This has been running for a few days without any 
problems now.

-----(TL;DR below)-----
Some background (partly recap from earlier thread, but some new facts, 
and also repeating here to keep it gathered):

This might be seen as "micro-optimization", not really useful if you 
have a small net with few sensors. However, with a couple of DS2406's 
wired as inputs, I want as low reaction time as possible. This is quite 
a big step towards that goal. Other optimizations I'm doing is of course 
simultaneous conversions and using alarms etc, but that's another story.

It all started with the random outages I wrote about in the other 
thread, in which I got some tips on the LinkUSB's different baudmodes. 
While looking into this, I also noticed that my DS2480B-based lab net 
performed much faster than the LinkUSB-based net. After some digging I 
found a few areas which could be improved.

It boils down to mainly two things:
* The FTDI FT232R (USB<->RS232) chip which the LinkUSB utilizes, does 
not perform well with low amounts of data. The 64byte data buffer is by 
default flushed every 16ms, or when full. Most OWFS operations does not 
produce those amounts of data, so every transaction was delayed up to 
16ms. This has been mitigated by changing the FTDi chip timer to 1ms, 
and this is also the main reason libftdi is used. (FTDI docs calls this 
the "latency timer")
* The LinkUSB operated at 9600bps by default. Every sent byte on the 
1-wire bus is transmitted hex encoded, so 2 bytes is used for every 
single wire-byte. The DS2480B uses raw bytes, thus the LinkUSB yielded 
half the speed. This has been mitigated by using 19200bps instead of 
9600bps. Higher speed (38400) is not usable, since it overruns the 
1-Wire bus unless we take special care of rate-limiting. Could maybe be 
used to speed up the search functionality..

A third thing I made some experiments on was the fact that OFWS jumps in 
and out of "byte" mode. However, trying to setting this mode explicitly 
and going in/out from it only when it was actually required, yielded 
worse timings in the end (with the above fixes applied).. Most likely 
since these changes where made in separate writes, taking up all the 
time which could potentially be gained. This experiment was ditched.

I also noticed that there was some issues with using the BREAK condition 
to reset my device. The manual says a BREAK condition should be able to 
reset the device. I'm communicating with iButtonLink regarding this, and 
they are looking in to it, believing I've found a bug.
Today I actually noticed that sending a break DOES work, but only when 
inside "b" mode (sending bytes to the wire). To be strict, the manual 
actually only talks about break support in the sections regarding the 
different data modes.. So might actually be working as intended.

Anyway, one brute force way of resetting would thus be to send "b", then 
break, then re-probe at 9600bps.. But I'll wait for further response 
from their developers before doing anything with this.

-----------

The changes adds the following:
* A LIBFTDI configure option: if not auto-detected/forced-yes, all ftdi 
related code is dropped out using similar conditionals as for example 
the W1 code.
* A new device arg: --linkusb=<serial> which tells owfs to use libftdi 
to find a specific USB device with that serial.
* Improved performance, if using the new device arg. Some examples:
Reading a DS18S20 temperature (12bit, after simultaneous conversion. 9 
byte response):
- Old LINK code: 123ms
(- Old LINK code with FTDI latency timer externally set to 1ms: 75ms)
- New LinkUSB FTDI code: 51ms
For the DS18B20 the improvement is actually even better, a separate 
commit is already merged into master [2], and without that fix the 
DS18B20 took 250ms.

Reading DS18*20 /power data (1 byte response):
- Old LINK code: 100ms
- New LinkUSB FTDI code: 43ms

The code is available in a branch on my fork: 
https://sourceforge.net/u/stromnet/owfs/ci/ftdi-linkusb/.

The changes can roughly be summarized:
* A new file ow_ftdi.c has been added, implementing a new com_type ct_ftdi
* ow_com* has been altered to support ct_ftdi in addition to ct_serial
* ow_link.c is mostly untouched, with exception for the Link detection 
code which now tries to detect a link device using multiple baud rates. 
For old link mode, this should not introduce any changes at all, except 
that it now has a chance to find devices configured for >9600bps.
* ow_arg changes to support new arg

To check this out locally, use:
git clone https://stromnet <at> git.code.sf.net/u/stromnet/owfs owfs-stromnet
git checkout ftdi-linkusb
Then follow the regular build-from-source commands as indicated in README.

Anyhow, I hope someone else finds these improvements interesting, and is 
willing to spend some time reviewing the changes, and also to do some 
testing with different OS'es and different Link12/Link45/LinkUSB 
versions (I only have a LinkUSB v1.5).
Ultimately my hope is of course that this makes it into the master branch.

I do have one thing on the todo list, and that is auto-detection. 
Currently you have to explicitly specify a LinkUSB FTDI serial number 
(Linux: lsusb, FreeBSD: usbconfig). This is not very optimal. However, 
at least my device uses the standard FTDI Vendor/product ID. This means 
I cannot distinguish a random FTDI-based RS232-adapter and a LinkUSB, 
without actually talking to the device. This can of course be done, but 
I'm not sure it's "acceptable" to start writing to every FTDI adapter 
found..

How is this solved with other auto-detected devices?

Looking forward to any and all feedback! :)
Johan

[1] 
https://sourceforge.net/p/owfs/mailman/owfs-developers/thread/53905A08.40906%40stromnet.se/#msg32422357
[2] https://sourceforge.net/p/owfs/code/merge-requests/1/

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems

Gmane