Loren Amelang | 29 Oct 19:59 2014
Picon

Config owfs to use server?

I'm still trying to understand whether I have a possible conflict with both owfs and server trying to read my
hardware. Something was updating the filesystem while server and httpd were not running...  My config is
part of the default Ubuntu distribution for 14.04, with just the "w1" added to point to my hardware. 

I notice in Roland's config he has set 
server: usb
like I have set 
server: w1
but he also sets 
owfs: server = 127.0.0.1:4304
and I have no equivalent line. 

I don't even see an "owfs" process running:
---
root      1151  0.0  0.1  20036   836 ?        Ssl  Oct19   1:56 /usr/bin/owftpd -c /etc/owfs.conf --pid-file /var/run/owfs/owftpd.pid
root     13064  0.0  0.1  11828  1000 ?        Ss   Oct26   0:00 /usr/bin/owhttpd -c /etc/owfs.conf --pid-file /var/run/owfs/owhttpd.pid
root     13605  0.0  0.2  53804  1168 ?        Ssl  Oct26   0:00 /usr/bin/owserver -c /etc/owfs.conf --pid-file /var/run/owfs/owserver.pid
---
It seems "owfs" can be used without the ftp/http/server modules, so it must exist on its own somehow. But
where? 

Should I add that "owfs: server = 127.0.0.1:4304" line to my config? Or does 
! server: server = localhost:4304
do the same thing, since it supposedly applies to everything except server? 

What about "owfs: pid_file = /var/run/owfs.pid"? I don't have an owfs.pid file on my system...  Just the
ftpd/httpd/server pid files. 

I see many configs with lines like "owfs: mountpoint = /mnt/1wire". I don't understand why one would mount
at /mnt/1wire when everything is already visible at /sys/devices/. 
(Continue reading)

Loren Amelang | 28 Oct 02:42 2014
Picon

Re: Owfs-developers Digest, Vol 101, Issue 23

Roberto,

Thank you for the clue about "/etc/init.d/owserver status" sometimes being unreliable. I suspect "sudo
service owserver status" might have the same issues? 

I was double-checking those results with: 
ps -ef |grep 'owfs'
root      1151     1  0 Oct19 ?        00:01:23 /usr/bin/owftpd -c /etc/owfs.conf --pid-file /var/run/owfs/owftpd.pid
root     13064     1  0 14:44 ?        00:00:00 /usr/bin/owhttpd -c /etc/owfs.conf --pid-file /var/run/owfs/owhttpd.pid
root     13605     1  0 15:27 ?        00:00:00 /usr/bin/owserver -c /etc/owfs.conf --pid-file /var/run/owfs/owserver.pid
(That's after I successfully restarted both processes.)

Mine always matched. It looked like owhttpd stopped serving pages a few minutes after owserver died, and
would not work until owserver was running again. 

I guess your netstat check has the advantage of proving the server is actually listening on the network,
rather than just running. 

Loren

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

> 1. Re: Updates while server not running, "simultaneous" kills
> it? (Stefano Miccoli)
> 
> Message: 1
> Date: Mon, 27 Oct 2014 00:39:18 +0100
> From: Stefano Miccoli <mocme <at> icloud.com>
> Subject: Re: [Owfs-developers] Updates while server not running,
> "simultaneous" kills it?
(Continue reading)

Loren Amelang | 26 Oct 23:55 2014
Picon

Updates while server not running, "simultaneous" kills it?

Paul,

Your comment about "two processes competing for the same resource" made me think of my random problem with
temperature values of "-62". My config file is just like the one at:
http://owfs.org/index.php?page=quickstart-guide

Except I (thought I had) commented the "server: FAKE = DS18S20,DS2405" line, 
and added "server: w1" right under the "#server: usb = all" line. 
---
# With this setup, any client (but owserver) uses owserver on the
# local machine...
! server: server = localhost:4304
#
# ...and owserver uses the real hardware, by default fake devices
# This part must be changed on real installation
! server: FAKE = DS18S20,DS2405
#
# USB device: DS9490
#server: usb = all
server: w1
---

I think I just learned something...  The manpage says:
---
server: opt = value # only owserver effected by this line 
! server: opt = value # owserver NOT effected by this line
---

What I missed until now is that "! server:" apparently DOES apply to everything BUT owserver. That makes
sense of the first command copied above - it tells everyone except server to read from server. 
(Continue reading)

Jim Lill | 26 Oct 10:47 2014

EDS 4-ch A/1W board

I have a Embedded Data Systems
EDS 4-ch A/1W board, an EDS0083 I believe and it is recognized but does not get all its data. Anybody else using one? -Jim
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Coudy | 25 Oct 20:58 2014
Picon

Missing data

Hi,
I'm using owfs with 19x DS18B20 temperature sensor with 2x DS9097 passive adapter. I have split my installation to two buses. Everything is running on my home NAS server (Core2Duo). I have problem with missing data. Sometimes data are not received.
I have tried it running as owserver and read data with owread/owget, and running as fuse mount point and read data with cat commad. Result is same. To store values I use Zabbix.

What is wrong, what should I change ? Is it issue with timeout or what ?

Thanks for any help.

Here are my system infos:
-----------------------------
this is my owfs.conf
#ALL
passive=/dev/ttyr00
passive=/dev/ttyr01
timeout_serial=5

#OwFS
mountpoint=/mnt/1wire
allow_other

# Display
format = f.i.c # 1-wire address f amily i d code c rc
alias=/etc/owfs.alias


-----------------------------
list of sensor on buses:
ls -l /mnt/1wire/bus.0
drwxrwxrwx 1 root root 4096 okt 25 20:35 pivnica_bojler
drwxrwxrwx 1 root root 4096 okt 25 20:35 pivnica_juzna
drwxrwxrwx 1 root root 4096 okt 25 20:35 pivnica_kurenie
drwxrwxrwx 1 root root 4096 okt 25 20:35 pivnica_kurenie_spiatocka
drwxrwxrwx 1 root root 4096 okt 25 20:35 pivnica_severna
drwxrwxrwx 1 root root 4096 okt 25 20:35 pivnica_tepla_voda
drwxrwxrwx 1 root root 4096 okt 25 20:35 pivnica_tepla_voda_spiatocka
drwxrwxrwx 1 root root 4096 okt 25 20:35 podkrovie_chodba
drwxrwxrwx 1 root root 4096 okt 25 20:35 podkrovie_spalna
drwxrwxrwx 1 root root 4096 okt 25 20:35 prizemie_hostovska
drwxrwxrwx 1 root root 4096 okt 25 20:35 prizemie_chodba
drwxrwxrwx 1 root root 4096 okt 25 20:35 prizemie_obyvacka_jv
drwxrwxrwx 1 root root 4096 okt 25 20:35 prizemie_spajza_dole
drwxrwxrwx 1 root root 4096 okt 25 20:35 prizemie_spajza_hore

ls -l /mnt/1wire/bus.1
drwxrwxrwx 1 root root 4096 okt 25 20:36 garaz
drwxrwxrwx 1 root root 4096 okt 25 20:36 pivnica_rack
drwxrwxrwx 1 root root 4096 okt 25 20:36 podkrovie_detska_j
drwxrwxrwx 1 root root 4096 okt 25 20:36 podkrovie_detska_s
drwxrwxrwx 1 root root 4096 okt 25 20:36 vonku


------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
David Lazarou | 25 Oct 04:57 2014
Picon

New Hobby Board barometer and humidity sensors

Hi All,

I recently purchased a new Hobby Board barometer and humidity sensor to add to my 1-wire network which uses a 1-wire USB adapter. However, while I do get data back from these devices, I see no barometric or humidity readings. I'm running the most recent code (owfs-2.9p8) which I noted supports these devices.
This is what I see when I do a directory listing of the devices:

barometer:

# ls -l /tmp/1-wire/EF.F69620150000
total 0
-r--r--r-- 1 root root  16 Oct 25 13:16 address
-rw-rw-rw- 1 root root 256 Oct 25 13:16 alias
-r--r--r-- 1 root root   2 Oct 25 13:16 crc8
-r--r--r-- 1 root root   2 Oct 25 13:16 family
-r--r--r-- 1 root root  12 Oct 25 13:16 id
-r--r--r-- 1 root root  16 Oct 25 13:16 locator
-r--r--r-- 1 root root  16 Oct 25 13:16 r_address
-r--r--r-- 1 root root  12 Oct 25 13:16 r_id
-r--r--r-- 1 root root  16 Oct 25 13:16 r_locator
-r--r--r-- 1 root root  32 Oct 25 13:16 type
-r--r--r-- 1 root root  12 Oct 25 13:17 type_number
-r--r--r-- 1 root root   7 Oct 25 13:17 version

humidity:

# ls -l /tmp/1-wire/EF.A05F20150000/
total 0
-r--r--r-- 1 root root  16 Oct 25 13:16 address
-rw-rw-rw- 1 root root 256 Oct 25 13:16 alias
-r--r--r-- 1 root root   2 Oct 25 13:16 crc8
-r--r--r-- 1 root root   2 Oct 25 13:16 family
-r--r--r-- 1 root root  12 Oct 25 13:16 id
-r--r--r-- 1 root root  16 Oct 25 13:16 locator
-r--r--r-- 1 root root  16 Oct 25 13:16 r_address
-r--r--r-- 1 root root  12 Oct 25 13:16 r_id
-r--r--r-- 1 root root  16 Oct 25 13:16 r_locator
-r--r--r-- 1 root root  32 Oct 25 13:16 type
-r--r--r-- 1 root root  12 Oct 25 13:18 type_number
-r--r--r-- 1 root root   7 Oct 25 13:18 version

I have both devices connected to a Hobby Board 4 channel hub.
I have tried running the owfs server from a Raspberry Pi running Archlinux and from a laptop running Fedora 19. However, I get exactly the same results.
I am successfully using other 1-wire devices on the network, so I don't thing there is any problems with the hardware.
Can any one confirm that they have successfully used these devices?

Thanks
David
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Vincent Danjean | 19 Oct 09:15 2014
Picon

Re: Bugreport for ow-shell

  Hi,

On 18/10/2014 12:27, Mario Gruenwald wrote:
> Hi
> 
> I tested it. Same problem in new Versions.

So, I'm currently forwarding your mail to upstream developers.

  Regards,
     Vincent

> http://blaeser.vc-graz.ac.at/ow-shell-bug.png
> I changed at 10 a.m.
> 
> My installed versions:
> sabi:~> dpkg -l | grep 'ii  ow' | cut -c -50
> ii  ow-shell                              2.9p7-2 
> ii  owfs-common                           2.9p7-2 
> ii  owserver                              2.9p7-2 
> sabi:~>
> 
> regards,
> Mario
> 
> On 2014-10-17, Vincent Danjean wrote:
>> On 17/10/2014 08:48, Mario Gruenwald wrote:
>>> Hi
>>>
>>> Thanx. Unfortunately testing is not as easy as i hoped.
>>> When i add repositories to my sources.list.d/... i don't see the new 
>>> packages. I checked, what i already installed. The list of packages is
>>> ow-shell, owfs-common, owserver
>>>
>>> So my idea was to manually download and install, but i am on i386 
>>> architecture and i miss owserver, i see only owserver_2.9p7-1_amd64.deb
>>
>> The package has been accepted by ftpmaster. It will be available
>> very soon for all Debian architectures. So I will not rebuild it for i386
>> myself. Just wait a few hours.
>>   Note: 2.9p7-1 and 2.9pp7-2 have the same software so you can
>> test with whatever will be present on your Debian mirrors.
>>   Let me know (and the owfs dev list too) if the bug is fixed or not
>> in 2.9p7 once you test it.
>>
>>   Regards,
>>     Vincent
>>
>>> Thanx in advance for any future support.
>>>
>>> Regards,
>>> Mario
>>>
>>> On 2014-10-17, Vincent Danjean wrote:
>>>>   I forgot to add my personal repo to test new packages in the
>>>> previous mail
>>>>
>>>> On 17/10/2014 07:21, Vincent Danjean wrote:
>>>>>   Hi
>>>>>
>>>>> On 17/10/2014 00:05, Mario Gruenwald wrote:
>>>>>> Hi
>>>>>>
>>>>>> I tried reportbug and reportbug-ng, but it was too difficult for me. 
>>>>>> Therefore i write an simple Email.
>>>>>>
>>>>>> I have an USB-1wire-Adapter and some DS18S20 temprature sensors. After my 
>>>>>> last upgrade of ow-shell from 2.8p15-1 to 2.9p5-1.1 my temperature graphs had 
>>>>>> steps. You can see the effect in a graph at:
>>>>>>   http://blaeser.vc-graz.ac.at/1wire.png
>>>>>> After downgrade the problem disappeared. You can see it at
>>>>>>   http://blaeser.vc-graz.ac.at/ow-shell-bug.png
>>>>>> starting from 19:00.
>>>>>>
>>>>>> I guess it is the same problem as here:
>>>>>> http://developer.mbed.org/users/snatch59/notebook/onewirecrc/
>>>>>> citation begin -----
>>>>>> I have an DS1820 and my values looked quite the same.
>>>>>>
>>>>>> I think the problem is with the calculation of the enhanced 9bit calculation 
>>>>>> in  DS18S20::calculateTemperature(BYTE* data)
>>>>>
>>>>> Indeed, it seems similar to effects describe in comments.
>>>>>
>>>>>> The manual of my DS1820 says:
>>>>>>
>>>>>> "After reading the scratchpad, the TEMP_READ value is obtained by truncating 
>>>>>> the 0.5C bit (bit 0) from the temperature data..."
>>>>>>
>>>>>> This truncation was missing in the code.
>>>>>>
>>>>>> I extended like this - which can be done better, I'm sure :-)   :
>>>>>> citation end -----
>>>>>>
>>>>>> It would be cool, if you can fix the current package for jessie or guide me, 
>>>>>> where and how to report the problem.
>>>>>
>>>>> I just uploaded yesterday the last version (2.9p7). It is on my personnal
>>>>> repo (see my signature) or in the NEW/BYHAND QUEUE (new library packages).
>>>>>   Please look if these new packages fix your problem. Else, I'm putting
>>>>> owfs developers in copy so that they can try to fix this bug.
>>>>>
>>>>>   Regards,
>>>>>     Vincent
>>>>>
>>>>>> kindly regards
>>>>>> Mario
>>>>>>
>>>>>
>>>>
>>>> -- 
>>>> Vincent Danjean       GPG key ID 0xD17897FA         vdanjean <at> debian.org
>>>> GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
>>>> Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
>>>> APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main
>>>>
>>>
>>
> 

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
Paul Alfille | 19 Oct 03:50 2014
Picon

New Release: 2.9p8

Sorry for the rapid releases, but some functional problems in the last two releases were serious enough to need fixing promptly -- specifically with the filesystem owfs.

-----------------------------

OWFS 2.9p8
Release Notes

Oct 18, 2014

One Wire File System

New Features
1. Filesystem fixed (owfs)
Old double-free mutex bug fixed
2. soelim utility now used for man file installation -- Stefano Miccoli
3. systemd now manages mountpoints -- Tomasz Torcz

Fixes
1. Numerous fixes from Coverity scan
Null serial number in alias file
Filelength calculation of directories
Pointer errors in owftpd
Fuse command line processing
2. swig gave error even with good write -- fixed
3. DS18S20 staircase bug fixed, again.
Vincent Danjean
Mario Gruenwald
4. OWFS (filesystem) wasn't honoring forground request
5. Clean up some Makefile problems (lint files)

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Owfs-developers mailing list
Owfs-developers <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Thomas Zimmermann | 18 Oct 11:48 2014
Picon

Bug: owfs crashes when browsing the the folder with dolphin

Hi,
I'm currently packaging owfs for openSUSE and got a bug report that in the 
package with systemd enabled owfs crashes as soon as one browses the /run/owfs 
folder with dolphin (KDE file manager).
Browsing the folder with ls works just fine.

To reproduce this I started owfs with the following parameters:
/usr/bin/owfs -u --server=127.0.0.1 --allow_other /run/owfs

The Backtrace looks like the following:
------------------------------------------------------------------------------------------------------------------------------------------------
[New Thread 0x7ffff658c700 (LWP 20156)]
[New Thread 0x7ffff5d8b700 (LWP 20158)]
1413624377 DEFAULT: ow_parsename.c:(316) debug_crash 1413624377.190662

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff658c700 (LWP 20156)]
0x00007ffff7b684d3 in FS_ParsedName_setup (pn=0x7ffff6588b60, path=0x7ffff0000af0 
"/", pp=0x7ffff6587ae0) at ow_parsename.c:316
316             CONNIN_RLOCK;
(gdb) bt
#0  0x00007ffff7b684d3 in FS_ParsedName_setup (pn=0x7ffff6588b60, 
path=0x7ffff0000af0 "/", pp=0x7ffff6587ae0) at ow_parsename.c:316
#1  FS_ParsedName_anywhere (path=0x7ffff0000af0 "/", 
remote_status=remote_status <at> entry=parse_pass_pre_remote, 
pn=pn <at> entry=0x7ffff6588b60) at ow_parsename.c:104
#2  0x00007ffff7b68cea in FS_ParsedName (path=<optimized out>, 
pn=pn <at> entry=0x7ffff6588b60) at ow_parsename.c:81
#3  0x00007ffff7b5ba3c in FS_fstat (path=<optimized out>, stbuf=0x7ffff658bc30) at 
ow_fstat.c:25
#4  0x00007ffff78a197d in ?? () from /lib64/libfuse.so.2
#5  0x00007ffff78ab895 in ?? () from /lib64/libfuse.so.2
#6  0x00007ffff78abdd6 in ?? () from /lib64/libfuse.so.2
#7  0x00007ffff78a8be9 in ?? () from /lib64/libfuse.so.2
#8  0x00007ffff767f0db in start_thread () from /lib64/libpthread.so.0
#9  0x00007ffff73b058d in clone () from /lib64/libc.so.6
(gdb) l
311             /* -- be added by Browse so  -- */
312             /* -- a reader/writer lock is - */
313             /* -- held until ParsedNameDestroy */
314             /* ---------------------------- */
315
316             CONNIN_RLOCK;
317             pn->selected_connection = NO_CONNECTION ; // Default bus 
assignment
318
319             return 0 ; // success
320     }
(gdb) p *pp
$2 = {pathcpy = '\000' <repeats 3448 times>..., pathnow = 0x0, pathnext = 
0x7ffff6587ae0 "", pathlast = 0x0}
(gdb) p *path
$3 = 47 '/'
(gdb) p *pn
$4 = {path = "/", '\000' <repeats 8192 times>, path_to_server = "/", '\000' 
<repeats 4096 times>, device_name = 0x0, known_bus = 0x0, type = ePN_root, 
state = ePS_normal, 
  sn = "\000\000\000\000\000\000\000", selected_device = 0x0, selected_filetype 
= 0x0, extension = 0, sparse_name = 0x0, subdir = 0x0, dirlength = 1, 
ds2409_depth = 0, bp = 0x0, 
  selected_connection = 0x0, control_flags = 330, lock = 0x0, return_code = 0, 
detail_flag = 0, tokens = 0, tokenstring = 0x0}

----------------------------------------------------------------------------------------------------------------------------------------------

It's compiled with the following options:

----------------------------------------------------------------------------------------------------------------------------------------------
./configure \
	--prefix=/usr \
	--libdir=/usr/lib64 \
	--disable-static \
	--enable-usb \
	--enable-owfs \
	--enable-owhttpd \
	--enable-owcapi \
	--enable-ownetlib \
	--enable-owftpd \
	--enable-owserver \
	--enable-owtap \
	--enable-owmon \
	--enable-owperl \
	--enable-owpython \
	--enable-owphp \
	--enable-owtcl \
	--with-systemdsystemunitdir=/usr/lib/systemd/system
----------------------------------------------------------------------------------------------------------------------------------------------

The package can be found here:
https://build.opensuse.org/package/show/home:Heinervdm:branches:home:Heinervdm:BGO-OD/owfs

If any further information is needed, i saved a core dump so that I can try to 
provide them.

Greetings,
Thomas

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
Vincent Danjean | 17 Oct 07:21 2014
Picon

Re: Bugreport for ow-shell

  Hi

On 17/10/2014 00:05, Mario Gruenwald wrote:
> Hi
> 
> I tried reportbug and reportbug-ng, but it was too difficult for me. 
> Therefore i write an simple Email.
> 
> I have an USB-1wire-Adapter and some DS18S20 temprature sensors. After my 
> last upgrade of ow-shell from 2.8p15-1 to 2.9p5-1.1 my temperature graphs had 
> steps. You can see the effect in a graph at:
>   http://blaeser.vc-graz.ac.at/1wire.png
> After downgrade the problem disappeared. You can see it at
>   http://blaeser.vc-graz.ac.at/ow-shell-bug.png
> starting from 19:00.
> 
> I guess it is the same problem as here:
> http://developer.mbed.org/users/snatch59/notebook/onewirecrc/
> citation begin -----
> I have an DS1820 and my values looked quite the same.
> 
> I think the problem is with the calculation of the enhanced 9bit calculation 
> in  DS18S20::calculateTemperature(BYTE* data)

Indeed, it seems similar to effects describe in comments.

> The manual of my DS1820 says:
> 
> "After reading the scratchpad, the TEMP_READ value is obtained by truncating 
> the 0.5C bit (bit 0) from the temperature data..."
> 
> This truncation was missing in the code.
> 
> I extended like this - which can be done better, I'm sure :-)   :
> citation end -----
> 
> It would be cool, if you can fix the current package for jessie or guide me, 
> where and how to report the problem.

I just uploaded yesterday the last version (2.9p7). It is on my personnal
repo (see my signature) or in the NEW/BYHAND QUEUE (new library packages).
  Please look if these new packages fix your problem. Else, I'm putting
owfs developers in copy so that they can try to fix this bug.

  Regards,
    Vincent

> kindly regards
> Mario
> 

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
Johan Ström | 15 Oct 00:02 2014
Picon

DS9097U and reliable BREAK reset

Hi,

I noticed on my DS9097U adapter, hooked on via FTDI USB dongle, that it 
would not come back up online after a owfs restart, if the latest 
executed command was in DATA mode.
After lots of testing and debugging, I got a patch which solves the 
problem. It introduces a 500ms delay before tcsendbreak. With this, it 
seems to work every time I tested.

How to reproduce:
$ owserver /dev/cuaXX --foreground --debug
...

Another console
$ owread /something # something which trigger a read, I used sensed.ALL 
on a ds2406

Now Ctrl-C owserver
Then, try to start owserver again. It will fail to reset and won't be 
found properly, complaining about wrong response:
   DEBUG: ow_ds9097U.c:(643) wrong response (0F not 00)

If I executed a dir before shutdown, it successfully started up again 
(since it was put in command mode).

I cannot really tell *why* it helps, or what causes it. It could be some 
OS-specific (FreeBSD) delays, or something with the FTDI dongle.
With the patch, the startup takes 500ms longer, but seems to work 
reliably every time. I did test with lower delays, but i.e. 200ms did 
not cut it.

/Johan

Diff against master:

diff --git a/module/owlib/src/c/ow_com.c b/module/owlib/src/c/ow_com.c
index 06b87fe..ae98a50 100644
--- a/module/owlib/src/c/ow_com.c
+++ b/module/owlib/src/c/ow_com.c
 <at>  <at>  -103,6 +103,7  <at>  <at>  void COM_break(struct connection_in *in)
                         LEVEL_DEBUG("Unimplemented!!!");
                         return ;
                 case ct_serial:
+                       usleep(500000);
                         tcsendbreak(in->pown->file_descriptor, 0);
                         break ;
         }

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho

Gmane