Digging deep into the problem, I solved my problem with this little patch.
Briefly, in shortcircuit situation _FromServer returns " " and not undef.
I think this patch is ok for me, but I suppose it can be good for others...
Also, I don't know if this is the best way to solve, or if it necessary to
inspect more deeply the _FromServer subroutine.
root@oscarbuntu:~# diff -c -N -r
/home/oscar/Downloads/owfs-2.8p14/module/ownet/perl5/OWNet/lib/OWNet.pm .
***
/home/oscar/Downloads/owfs-2.8p14/module/ownet/perl5/OWNet/lib/OWNet.pm
2011-03-24 02:40:39.000000000 +0100
--- ./OWNet.pm 2012-04-20 15:05:22.713276093 +0200
***************
*** 615,620 ****
--- 615,621 ----
# new MSG_DIRALL method -- single packet
_ToServer($self,$MSG_DIRALL,$DEFAULT_BLOCK_LENGTH,$NO_OFFSET,$path)
|| return ;
my @r = _FromServer($self) ;
+ return if !@r ;
if (@r) {
$self->{SOCK} = undef if $self->{PERSIST} == 0 ;
return $r[6] ;
Il giorno 18 aprile 2012 17:01, <owfs-developers-ow...@lists.sourceforge.net
> ha scritto:
>
> I'm doing a little "access control" based on iButton (DS1990A). It is read
> with an usb key (DS9490R). The usb is accessed via owserver, and my perl
> script uses OWNet.pm library.
>
> While scripting I encountered this error:
>
> Use of uninitialized value $r[1] in numeric eq (==) at
> /usr/local/share/perl/5.10.1/OWNet.pm line 630.
> substr outside of string at /usr/local/share/perl/5.10.1/OWNet.pm line 632.
>
> After such error, my script goes wrong, getting inconsistent data from
> owserver. I noticed that in reply of a $owserver->dir("/") loop, data are
> returned 1 at time instead of all-together, or the iButton result present
> randomly for a long time after I detached it...
>
> After a lot of test I can replicate the error short circuiting the iButton
> probe. I encountered it the first time while testing the script: sometimes
> attaching/detaching rapidly the iButton can do it, because while it is non
> perfectly inserted the border... :( As a confirm, I also found (later...
> :( ) this log from owserver:
>
> CALL: ow_dir.c:(98) path=/
> DATA: ow_usb_msg.c:(183) Status byte[0]: A
> DATA: ow_usb_msg.c:(186) short detected
> CONNECT: ow_reset.c:(36) 1-wire bus short circuit.
> DATA: ow_ds9490.c:(687) CRC error
>
>
> I also tried to solve it inserting a little resistance in series of the
> probe, but the error is still there.
> May be the resistance too little? Mmm, I don't think it: I tested
> different resistance: if it is big, I don't see the iButton, else I got the
> error...
> On the other hand, is correct: is part of the "resistance" of the protocol
> recognize this type of problems.
> Only I did not expect to find traces, in another way, in my script: (
>
> I'd like to know if the lib error is a "correct" behavior (or
> uncorrectable).
>
>
> I'm working on Ubuntu 11.04 - Perl 5.10 and owfs 2.8p14
>
> A simplified script I used to replicate my error is this:
>
> #!/usr/bin/perl
> use strict;
> #use warnings;
> use FileHandle;
> use POSIX;
> use Time::HiRes qw(usleep);
> use OWNet ;
>
> use constant DEBUG => 1;
>
> my $owserver = OWNet->new( "localhost:4304" ) ;
>
> # Workaround for buffer problem
> my $new_stdout = FileHandle->new_from_fd(dup(fileno(STDOUT)), 'w');
> $new_stdout->autoflush(1);
>
>
> my @key_found;
>
> sub scan_bus {
> my $dir_list = $owserver->dir('/');
> if ( defined($dir_list) ) {
> @key_found = split /,/ , $dir_list;
> }
> print { $new_stdout } "\ndir_list @key_found\n" if DEBUG; }
>
> while ( 1 ) {
> &scan_bus;
> usleep(100000);
> print { $new_stdout } ".\n" if DEBUG;
> }
>
> -----------------------
>
> For completeness, I use this /etc/owfs.conf file:
>
> usb
> link=127.0.0.1:4304
> Celsius
> pid_file = /var/run/owserver.pid
> uncached
> foreground
> error_print 2
> error_level 4
> # Timeouts (all in seconds)
> # cache for values that change on their own timeout_volatile = 1 # seconds
> "volatile" values remain in cache # cache for values that change on command
> timeout_stable = 4 # seconds "stable" values remain in cache # cache for
> directory lists (non-alarm) timeout_directory = 1 # seconds "directory"
> values remain in cache # cache for 1-wire device location timeout_presence
> = 4 # seconds "device presence" (which bus)
> timeout_ha7 = 1
> timeout_w1 = 1
>
> Thanks
>
> Giulio Carabetta
>
>
>
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
