Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link
allrighty then... On 12.09.2017 19:35, Johan Ström wrote: Thanks for verification, fix is now pushed to master :) -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link
Thanks for verification, fix is now pushed to master :)
On 12/09/17 15:38, Martin Patzak (GMX) wrote:
tried your patch right away and it works! Small change, big difference ;)
I tested on platform amd64 all successful with options
-d /dev/ttyUSB0 # emulated mode
--link = /dev/ttyUSB0 # serial mode
--link = ftdi:AK0048A0 # FTDI direct communication mode
Thank you,
Martin
On 11.09.2017 21:50, Johan Ström wrote:
Hi,
just took a closer look at the patch Hans-Frieders sent earlier. The
only thing it (effectively) does, when applied to the current owfs
version, is to do more identical probes:
It sets baud/flow to something, then calls LINK_detect_serial(..). If
it fails, it does this with a few different baud/flow settings.
The thing is that the current version of LINK_detect_serial will
overwrite those baud/flow settings anyway, and probe with a bunch of
combinations.
So effectively, that patch is just calling LINK_detect_serial() 4
times instead of 1 time.
Or at least, that's what I thought first.. For the ct_serial path, it
also makes sure that gbGOOD is actually returned. In current code,
the ct_ftdi path will return gbGOOD, but ct_serial path will only
explicitly return BAD from LINK_detect_serial, not gbGOOD. For gbGOOD
it drops through and returns gbBAd...
Can (both of you, if possible) try the following patch? It will
hopefully help you.
diff --git a/module/owlib/src/c/ow_link.c b/module/owlib/src/c/ow_link.c
index 34eed196..93c45935 100644
--- a/module/owlib/src/c/ow_link.c
+++ b/module/owlib/src/c/ow_link.c
@@ -282,6 +282,8 @@ GOOD_OR_BAD LINK_detect(struct port_in *pin)
// ensure still found
RETURN_GOOD_IF_GOOD( LINK_version(in) ) ;
ERROR_CONNECT("LINK baud reconfigure
failed, cannot find it after 19200 change.");
+ } else {
+ return gbGOOD;
}
break;
}
If you can verify that it helps, I'll patch the code I broke when
introducing ftdi support.. and it will go in next release.. :)
Johan
On 11/09/17 08:09, Martin Patzak (GMX) wrote:
Thanks for confirming.
If you want to, you can try the patch that Hans-Frieder Vogt sent to
this board. It worked for the LinkUSB.
On 10.09.2017 22:45, Nicolas Huillard wrote:
Le vendredi 21 juillet 2017 à 10:47 +0200, Martin Patzak (GMX) a
écrit :
I am trying to start owserver with a LinkUSB V 1.7 as bus master
using
the option /--link/.
I am able to start owserver with the LinkUSB V 1.7 and V 1.4 using
the
option "d" for device without any problems.
I can confirm the same behaviour here. I just upgraded my Raspberry Pi
to Raspbian stretch with owfs 3.1p5 (from squeeze with owfs 2.8). The
serial LINK is not recognised with the --link option, but OK with --
device. I didn't change anything else, juste upgraded the system.
Here are the logs :
root@raspberry:~# owserver -V
owserver version:
3.1p5
libow version:
3.1p5
root@raspberry:~# owserver --link=/dev/owlink --foreground --error_level=9
DEBUG: ow_daemon.c:(170) main thread id = 3069931600
DEBUG: ow_inotify.c:(80) No configuration files to monitor
CONNECT: ow_dnssd.c:(81) Zeroconf/Bonjour is disabled since dnssd library isn't
found
CALL: ow_parsename.c:(104) path=[]
DEBUG: owlib.c:(77) Global temp limit 0C to 100C (for fake and mock adapters)
DEBUG: ow_com.c:(47) Auto initialization of /dev/owlink
DEBUG: ow_link.c:(328) Detecting serial LINK using 9600 bps
DEBUG: ow_link.c:(360) Slurp in initial bytes
DEBUG: ow_link.c:(431) Checking LINK version
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1
Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link
tried your patch right away and it works! Small change, big difference ;)
I tested on platform amd64 all successful with options
-d /dev/ttyUSB0 # emulated mode
--link = /dev/ttyUSB0 # serial mode
--link = ftdi:AK0048A0# FTDI direct communication mode
Thank you,
Martin
On 11.09.2017 21:50, Johan Ström wrote:
Hi,
just took a closer look at the patch Hans-Frieders sent earlier. The
only thing it (effectively) does, when applied to the current owfs
version, is to do more identical probes:
It sets baud/flow to something, then calls LINK_detect_serial(..). If
it fails, it does this with a few different baud/flow settings.
The thing is that the current version of LINK_detect_serial will
overwrite those baud/flow settings anyway, and probe with a bunch of
combinations.
So effectively, that patch is just calling LINK_detect_serial() 4
times instead of 1 time.
Or at least, that's what I thought first.. For the ct_serial path, it
also makes sure that gbGOOD is actually returned. In current code, the
ct_ftdi path will return gbGOOD, but ct_serial path will only
explicitly return BAD from LINK_detect_serial, not gbGOOD. For gbGOOD
it drops through and returns gbBAd...
Can (both of you, if possible) try the following patch? It will
hopefully help you.
diff --git a/module/owlib/src/c/ow_link.c b/module/owlib/src/c/ow_link.c
index 34eed196..93c45935 100644
--- a/module/owlib/src/c/ow_link.c
+++ b/module/owlib/src/c/ow_link.c
@@ -282,6 +282,8 @@ GOOD_OR_BAD LINK_detect(struct port_in *pin)
// ensure still found
RETURN_GOOD_IF_GOOD( LINK_version(in) ) ;
ERROR_CONNECT("LINK baud reconfigure
failed, cannot find it after 19200 change.");
+ } else {
+ return gbGOOD;
}
break;
}
If you can verify that it helps, I'll patch the code I broke when
introducing ftdi support.. and it will go in next release.. :)
Johan
On 11/09/17 08:09, Martin Patzak (GMX) wrote:
Thanks for confirming.
If you want to, you can try the patch that Hans-Frieder Vogt sent to
this board. It worked for the LinkUSB.
On 10.09.2017 22:45, Nicolas Huillard wrote:
Le vendredi 21 juillet 2017 à 10:47 +0200, Martin Patzak (GMX) a
écrit :
I am trying to start owserver with a LinkUSB V 1.7 as bus master
using
the option /--link/.
I am able to start owserver with the LinkUSB V 1.7 and V 1.4 using
the
option "d" for device without any problems.
I can confirm the same behaviour here. I just upgraded my Raspberry Pi
to Raspbian stretch with owfs 3.1p5 (from squeeze with owfs 2.8). The
serial LINK is not recognised with the --link option, but OK with --
device. I didn't change anything else, juste upgraded the system.
Here are the logs :
root@raspberry:~# owserver -V
owserver version:
3.1p5
libow version:
3.1p5
root@raspberry:~# owserver --link=/dev/owlink --foreground --error_level=9
DEBUG: ow_daemon.c:(170) main thread id = 3069931600
DEBUG: ow_inotify.c:(80) No configuration files to monitor
CONNECT: ow_dnssd.c:(81) Zeroconf/Bonjour is disabled since dnssd library isn't
found
CALL: ow_parsename.c:(104) path=[]
DEBUG: owlib.c:(77) Global temp limit 0C to 100C (for fake and mock adapters)
DEBUG: ow_com.c:(47) Auto initialization of /dev/owlink
DEBUG: ow_link.c:(328) Detecting serial LINK using 9600 bps
DEBUG: ow_link.c:(360) Slurp in initial bytes
DEBUG: ow_link.c:(431) Checking LINK version
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63)
Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link
Hi,
just took a closer look at the patch Hans-Frieders sent earlier. The
only thing it (effectively) does, when applied to the current owfs
version, is to do more identical probes:
It sets baud/flow to something, then calls LINK_detect_serial(..). If it
fails, it does this with a few different baud/flow settings.
The thing is that the current version of LINK_detect_serial will
overwrite those baud/flow settings anyway, and probe with a bunch of
combinations.
So effectively, that patch is just calling LINK_detect_serial() 4 times
instead of 1 time.
Or at least, that's what I thought first.. For the ct_serial path, it
also makes sure that gbGOOD is actually returned. In current code, the
ct_ftdi path will return gbGOOD, but ct_serial path will only explicitly
return BAD from LINK_detect_serial, not gbGOOD. For gbGOOD it drops
through and returns gbBAd...
Can (both of you, if possible) try the following patch? It will
hopefully help you.
diff --git a/module/owlib/src/c/ow_link.c b/module/owlib/src/c/ow_link.c
index 34eed196..93c45935 100644
--- a/module/owlib/src/c/ow_link.c
+++ b/module/owlib/src/c/ow_link.c
@@ -282,6 +282,8 @@ GOOD_OR_BAD LINK_detect(struct port_in *pin)
// ensure still found
RETURN_GOOD_IF_GOOD( LINK_version(in) ) ;
ERROR_CONNECT("LINK baud reconfigure
failed, cannot find it after 19200 change.");
+ } else {
+ return gbGOOD;
}
break;
}
If you can verify that it helps, I'll patch the code I broke when
introducing ftdi support.. and it will go in next release.. :)
Johan
On 11/09/17 08:09, Martin Patzak (GMX) wrote:
Thanks for confirming.
If you want to, you can try the patch that Hans-Frieder Vogt sent to
this board. It worked for the LinkUSB.
On 10.09.2017 22:45, Nicolas Huillard wrote:
Le vendredi 21 juillet 2017 à 10:47 +0200, Martin Patzak (GMX) a
écrit :
I am trying to start owserver with a LinkUSB V 1.7 as bus master
using
the option /--link/.
I am able to start owserver with the LinkUSB V 1.7 and V 1.4 using
the
option "d" for device without any problems.
I can confirm the same behaviour here. I just upgraded my Raspberry Pi
to Raspbian stretch with owfs 3.1p5 (from squeeze with owfs 2.8). The
serial LINK is not recognised with the --link option, but OK with --
device. I didn't change anything else, juste upgraded the system.
Here are the logs :
root@raspberry:~# owserver -V
owserver version:
3.1p5
libow version:
3.1p5
root@raspberry:~# owserver --link=/dev/owlink --foreground --error_level=9
DEBUG: ow_daemon.c:(170) main thread id = 3069931600
DEBUG: ow_inotify.c:(80) No configuration files to monitor
CONNECT: ow_dnssd.c:(81) Zeroconf/Bonjour is disabled since dnssd library isn't
found
CALL: ow_parsename.c:(104) path=[]
DEBUG: owlib.c:(77) Global temp limit 0C to 100C (for fake and mock adapters)
DEBUG: ow_com.c:(47) Auto initialization of /dev/owlink
DEBUG: ow_link.c:(328) Detecting serial LINK using 9600 bps
DEBUG: ow_link.c:(360) Slurp in initial bytes
DEBUG: ow_link.c:(431) Checking LINK version
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds
DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1
DEBUG: ow_link.c:(199) Link version Found 1.0
CONNECT: owlib.c:(216) Cannot open LINK bus master at /dev/owlink
DEBUG:
Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link
Thanks for confirming. If you want to, you can try the patch that Hans-Frieder Vogt sent to this board. It worked for the LinkUSB. On 10.09.2017 22:45, Nicolas Huillard wrote: Le vendredi 21 juillet 2017 à 10:47 +0200, Martin Patzak (GMX) a écrit : I am trying to start owserver with a LinkUSB V 1.7 as bus master using the option /--link/. I am able to start owserver with the LinkUSB V 1.7 and V 1.4 using the option "d" for device without any problems. I can confirm the same behaviour here. I just upgraded my Raspberry Pi to Raspbian stretch with owfs 3.1p5 (from squeeze with owfs 2.8). The serial LINK is not recognised with the --link option, but OK with -- device. I didn't change anything else, juste upgraded the system. Here are the logs : root@raspberry:~# owserver -V owserver version: 3.1p5 libow version: 3.1p5 root@raspberry:~# owserver --link=/dev/owlink --foreground --error_level=9 DEBUG: ow_daemon.c:(170) main thread id = 3069931600 DEBUG: ow_inotify.c:(80) No configuration files to monitor CONNECT: ow_dnssd.c:(81) Zeroconf/Bonjour is disabled since dnssd library isn't found CALL: ow_parsename.c:(104) path=[] DEBUG: owlib.c:(77) Global temp limit 0C to 100C (for fake and mock adapters) DEBUG: ow_com.c:(47) Auto initialization of /dev/owlink DEBUG: ow_link.c:(328) Detecting serial LINK using 9600 bps DEBUG: ow_link.c:(360) Slurp in initial bytes DEBUG: ow_link.c:(431) Checking LINK version DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_link.c:(199) Link version Found 1.0 CONNECT: owlib.c:(216) Cannot open LINK bus master at /dev/owlink DEBUG: ow_serial_free.c:(40) COM_close: flush DEBUG: ow_serial_free.c:(42) COM_close: restore DEFAULT: owlib.c:(52) No valid 1-wire buses found DEBUG: ow_exit.c:(17) Exit code = 1 ... root@raspberry:~# ls -l /dev/owlink lrwxrwxrwx 1 root root 7 sept. 10 21:39 /dev/owlink -> ttyUSB2 What seams to be the problem? Anybody seen this before? I've never seen that before. owfs and my serial LINK have both been very reliable since at least 2003... -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link
Le vendredi 21 juillet 2017 à 10:47 +0200, Martin Patzak (GMX) a écrit : > I am trying to start owserver with a LinkUSB V 1.7 as bus master > using > the option /--link/. > I am able to start owserver with the LinkUSB V 1.7 and V 1.4 using > the > option "d" for device without any problems. I can confirm the same behaviour here. I just upgraded my Raspberry Pi to Raspbian stretch with owfs 3.1p5 (from squeeze with owfs 2.8). The serial LINK is not recognised with the --link option, but OK with -- device. I didn't change anything else, juste upgraded the system. Here are the logs : root@raspberry:~# owserver -V owserver version: 3.1p5 libow version: 3.1p5 root@raspberry:~# owserver --link=/dev/owlink --foreground --error_level=9 DEBUG: ow_daemon.c:(170) main thread id = 3069931600 DEBUG: ow_inotify.c:(80) No configuration files to monitor CONNECT: ow_dnssd.c:(81) Zeroconf/Bonjour is disabled since dnssd library isn't found CALL: ow_parsename.c:(104) path=[] DEBUG: owlib.c:(77) Global temp limit 0C to 100C (for fake and mock adapters) DEBUG: ow_com.c:(47) Auto initialization of /dev/owlink DEBUG: ow_link.c:(328) Detecting serial LINK using 9600 bps DEBUG: ow_link.c:(360) Slurp in initial bytes DEBUG: ow_link.c:(431) Checking LINK version DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_link.c:(199) Link version Found 1.0 CONNECT: owlib.c:(216) Cannot open LINK bus master at /dev/owlink DEBUG: ow_serial_free.c:(40) COM_close: flush DEBUG: ow_serial_free.c:(42) COM_close: restore DEFAULT: owlib.c:(52) No valid 1-wire buses found DEBUG: ow_exit.c:(17) Exit code = 1 ... root@raspberry:~# ls -l /dev/owlink lrwxrwxrwx 1 root root 7 sept. 10 21:39 /dev/owlink -> ttyUSB2 > What seams to be the problem? Anybody seen this before? I've never seen that before. owfs and my serial LINK have both been very reliable since at least 2003... -- Nicolas Huillard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link
Hi all,
Gesendet: Dienstag, 08. August 2017 um 21:29 Uhr
Von: "Martin Patzak (GMX)" <martin.pat...@gmx.de>
An: "OWFS (One-wire file system) discussion and help" <owfs-developers@lists.sourceforge.net>
Betreff: Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link
On 07.08.2017 21:43, Johan Ström wrote:
...
Great that you got it working :) But man page could perhaps be improved then. If you have any suggestions, please feel free to provide them through a patch or on mailing list. Source is at https://sourceforge.net/p/owfs/code/ci/master/tree/src/man/man1/device.1so
yes, I have to check, why I did not understand the meaning of the words in the manual;) - however I understood your words very clearly:
With "--link=/dev/ttyUSB0" it would access it as serial device (no ftdi required).
With "--link=ftdi:XXX (XXX as per man page) it would use libftdi for direct communication.
maybe something like this should be in the manual... I might be able to contribute once I fully understand - someday soon hopefully :)
I got no debug output at all. But an entry in syslog was found, that the debian package had been build without ftdi option - well thats unfortunate ;)
Did the owserver process stay alive after this? I usually run testing with flags --foreground --fatal_debug to have all debug output on stdout, and not daemonize.
There should be an util named owusbprobe which can help you to scan devices and give some hints on how to address it.
No, the owserver process when using flags --debug (and debug implies foreground, thus preventing daemonization) dies without debug message - but entry in syslog is there:
ow_arg.c:(85) FTDI support not included in compilation.
your flags --foreground --fatal_debug also yield the same result.
Unrelated: do not run owserver with sudo. In this particular case (ftdi), it might be an easy workaround for fixing the device permissions. Besides that, there is no reason at all to run as root, and is never recommended.
Don't remember from the top of my head, but you will need to chown/chgrp some node in /dev/usb/something for that particular user. Not sure if that was ever documented properly..
Yes, thank you for pointing that out, I have some issues with that and the ftdi command, but I will write this in a separate message to the board.
Of course, it does not explain why the access as serial device without ftdi fails.
But maybe thats a moot point, since you might as well access it in emulated DS2408B-mode, which works fine.
Just to be clear, which parameters are you using when it is not working (and is this with latest version as well? or dependent on compile options?)?
the serial mode with link=/dev/ttyUSB0 does NOT work in either the pre-built debian package 3.1p5 nor in my self-built owserver from git-source 3.2p1.
When started with your suggested flags --fatal_debug --foreground the message is
DEFAULT: owlib.c:(52) No valid 1-wire buses found
As before-mentioned the ftdi mode with link=ftdi:XXX does NOT work with the pre-built debian package, because the option ftdi was disabled. And it works as expected when enabling it and building from git-source 3.2p1.
Martin
-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
try the attached small patch. For me it did the trick to get back the linkUSB (and linkOEM) support. It is copied from an old (I forgot which) version of owfs.
Cheers,
Hans-Frieder
--- a/module/owlib/src/c/ow_link.c 2016-03-16 11:46:14.0 +0100
+++ b/module/owlib/src/c/ow_link.c 2017-01-17 22:37:18.224591922 +0100
@@ -258,6 +258,24 @@ GOOD_OR_BAD LINK_detect(struct port_in *
case ct_serial:
+ pin->baud = B9600 ;
+
+ pin->flow = flow_first ;
+ RETURN_GOOD_IF_GOOD( LINK_detect_serial(in) ) ;
+
+ LEVEL_DEBUG("Second attempt at serial LINK setup");
+ pin->flow = flow_second ;
+ RETURN_GOOD_IF_GOOD( LINK_detect_serial(in) ) ;
+
+ LEVEL_DEBUG("Third attempt at serial LINK setup");
+ pin->flow = flow_first ;
+ RETURN_GOOD_IF_GOOD( LINK_detect_serial(in) ) ;
+
+ LEVEL_DEBUG("Fourth attempt at serial LINK setup");
+ pin->flow = flow_second ;
+ RETURN_GOOD_IF_GOOD( LINK_detect_serial(in) ) ;
+ break ;
+
case ct_ftdi:
{
/* The LINK (both regular and USB) can run in different baud modes.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link
On 07.08.2017 21:51, Matthias Urlichs via Owfs-developers wrote: On 07.08.2017 21:43, Johan Ström wrote: Don't remember from the top of my head, but you will need to chown/chgrp some node in /dev/usb/something for that particular user. Not sure if that was ever documented properly.. There are lots of examples on the net how to write an udev rule which does that. Yes, Matthias, there are. The udev rule I use for the LinkUSB and owserver does not work with the option ftdi. I will write this issue in a separate email to the board. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link
On 07.08.2017 21:43, Johan Ström wrote: ... Great that you got it working :) But man page could perhaps be improved then. If you have any suggestions, please feel free to provide them through a patch or on mailing list. Source is at https://sourceforge.net/p/owfs/code/ci/master/tree/src/man/man1/device.1so yes, I have to check, why I did not understand the meaning of the words in the manual;) - however I understood your words very clearly: With "--link=/dev/ttyUSB0" it would access it as serial device (no ftdi required). With "--link=ftdi:XXX (XXX as per man page) it would use libftdi for direct communication. maybe something like this should be in the manual... I might be able to contribute once I fully understand - someday soon hopefully :) I got no debug output at all. But an entry in syslog was found, that the debian package had been build without ftdi option - well thats unfortunate ;) Did the owserver process stay alive after this? I usually run testing with flags --foreground --fatal_debug to have all debug output on stdout, and not daemonize. There should be an util named owusbprobe which can help you to scan devices and give some hints on how to address it. No, the owserver process when using flags --debug (and debug implies foreground, thus preventing daemonization) dies without debug message - but entry in syslog is there: /ow_arg.c:(85) FTDI support not included in compilation./ your flags --foreground --fatal_debug also yield the same result. Unrelated: do not run owserver with sudo. In this particular case (ftdi), it might be an easy workaround for fixing the device permissions. Besides that, there is no reason at all to run as root, and is never recommended. Don't remember from the top of my head, but you will need to chown/chgrp some node in /dev/usb/something for that particular user. Not sure if that was ever documented properly.. Yes, thank you for pointing that out, I have some issues with that and the ftdi command, but I will write this in a separate message to the board. Of course, it does not explain why the access as serial device without ftdi fails. But maybe thats a moot point, since you might as well access it in emulated DS2408B-mode, which works fine. Just to be clear, which parameters are you using when it is not working (and is this with latest version as well? or dependent on compile options?)? the serial mode with link=/dev/ttyUSB0 does NOT work in either the pre-built debian package 3.1p5 nor in my self-built owserver from git-source 3.2p1. When started with your suggested flags --fatal_debug --foreground the message is / DEFAULT: owlib.c:(52) No valid 1-wire buses found/ As before-mentioned the ftdi mode with link=ftdi:XXX does NOT work with the pre-built debian package, because the option ftdi was disabled. And it works as expected when enabling it and building from git-source 3.2p1. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link
On 07.08.2017 21:43, Johan Ström wrote: > Don't remember from the top of my head, but you will need to > chown/chgrp some node in /dev/usb/something for that particular user. > Not sure if that was ever documented properly.. There are lots of examples on the net how to write an udev rule which does that. -- -- Matthias Urlichs -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link
On 06/08/17 22:17, Martin Patzak (GMX) wrote: On 04.08.2017 11:09, Johan Ström wrote: Main reason for using the --link option would be the increased performance by factor 2! Not 100% correct. LinkUSB can be used through regular serial device just fine without libftdi & libusb. However, if owfs is built with libftdi and it is used instead of using a serial tty, the performance is improved as Martin writes. With "--link=/dev/ttyUSB0" it would access it as serial device (no ftdi required). With "--link=ftdi:XXX (XXX as per man page) it would use libftdi for direct communication. Ok, thanks Johan, for clearing this one up, which in turn got me building from source and solving the issue. This difference in accessing it in two separate modes was not understood by me from reading the man-page. Great that you got it working :) But man page could perhaps be improved then. If you have any suggestions, please feel free to provide them through a patch or on mailing list. Source is at https://sourceforge.net/p/owfs/code/ci/master/tree/src/man/man1/device.1so You could also try "--device=/dev/ttyUSB0" to use in "emulated DS2408B-mode" yes this works fine. I had owfs 3.1p5 installed from a debian package. So, when I tried to access the LinkUSB with option "i" using the USB vendor and device number of the LinkUSB V1.7 sudo owserver --link=ftdi:i:0x0403:0x6001 --debug I got no debug output at all. But an entry in syslog was found, that the debian package had been build without ftdi option - well thats unfortunate ;) Did the owserver process stay alive after this? I usually run testing with flags --foreground --fatal_debug to have all debug output on stdout, and not daemonize. There should be an util named owusbprobe which can help you to scan devices and give some hints on how to address it. Unrelated: do not run owserver with sudo. In this particular case (ftdi), it might be an easy workaround for fixing the device permissions. Besides that, there is no reason at all to run as root, and is never recommended. Don't remember from the top of my head, but you will need to chown/chgrp some node in /dev/usb/something for that particular user. Not sure if that was ever documented properly.. After *building the newest owserver* from git source 3.2p1 *with the ftdi option enabled it works as expected* with LinkUSB V1.7 as well as V1.4 (so far it runs - I did not have time to do performance tests) here is the excerpt from the debug (note: the command is owserver_LinkUSB because I built it with that name to keep the debian packaged version separate) /sudo owserver_LinkUSB --link=ftdi:i:0x0403:0x6001 --debug ... DEBUG: ow_link.c:(218) Link version is unrecognized: LinkUSB V1.7 (but that's ok). DEBUG: ow_net_server.c:(76) ServerAddr: [0.0.0.0] [4304] / So, again, thank you Johan for pointing out the detail with the ftdi addressing scheme, which got me building from source which solved the problem for me. Great! Of course, it does not explain why the access as serial device without ftdi fails. But maybe thats a moot point, since you might as well access it in emulated DS2408B-mode, which works fine. Just to be clear, which parameters are you using when it is not working (and is this with latest version as well? or dependent on compile options?)? Johan -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link
On 04.08.2017 11:09, Johan Ström wrote: Main reason for using the --link option would be the increased performance by factor 2! Not 100% correct. LinkUSB can be used through regular serial device just fine without libftdi & libusb. However, if owfs is built with libftdi and it is used instead of using a serial tty, the performance is improved as Martin writes. With "--link=/dev/ttyUSB0" it would access it as serial device (no ftdi required). With "--link=ftdi:XXX (XXX as per man page) it would use libftdi for direct communication. Ok, thanks Johan, for clearing this one up, which in turn got me building from source and solving the issue. This difference in accessing it in two separate modes was not understood by me from reading the man-page. You could also try "--device=/dev/ttyUSB0" to use in "emulated DS2408B-mode" yes this works fine. I had owfs 3.1p5 installed from a debian package. So, when I tried to access the LinkUSB with option "i" using the USB vendor and device number of the LinkUSB V1.7 sudo owserver --link=ftdi:i:0x0403:0x6001 --debug I got no debug output at all. But an entry in syslog was found, that the debian package had been build without ftdi option - well thats unfortunate ;) After *building the newest owserver* from git source 3.2p1 *with the ftdi option enabled it works as expected* with LinkUSB V1.7 as well as V1.4 (so far it runs - I did not have time to do performance tests) here is the excerpt from the debug (note: the command is owserver_LinkUSB because I built it with that name to keep the debian packaged version separate) /sudo owserver_LinkUSB --link=ftdi:i:0x0403:0x6001 --debug DEBUG MODE libow version: 3.2p1 DEBUG: ow_daemon.c:(170) main thread id = 140604669374976 DEBUG: ow_inotify.c:(80) No configuration files to monitor CONNECT: ow_dnssd.c:(81) Zeroconf/Bonjour is disabled since dnssd library isn't found CALL: ow_parsename.c:(104) path=[] DEBUG: owlib.c:(77) Global temp limit 0C to 100C (for fake and mock adapters) DEBUG: ow_com.c:(47) Auto initialization of ftdi:i:0x0403:0x6001 DEBUG: ow_ftdi.c:(202) Sending FTDI break.. DEBUG: ow_link.c:(328) Detecting ftdi LINK using 9600 bps DEBUG: ow_ftdi.c:(202) Sending FTDI break.. DEBUG: ow_link.c:(360) Slurp in initial bytes DEBUG: ow_ftdi.c:(484) ftdi_write: 1 = actual 1 DEBUG: ow_link.c:(431) Checking LINK version DEBUG: ow_ftdi.c:(402) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_ftdi.c:(463) ftdi_read: 1 - 0 = 1 (3 retries) ... DEBUG: ow_link.c:(218) Link version is unrecognized: LinkUSB V1.7 (but that's ok). DEBUG: ow_link.c:(278) Reconfiguring found LinkUSB to 19200bps DEBUG: ow_link.c:(500) LINK set baud to 19200 DEBUG: ow_link.c:(525) LINK change baud string <,> DEBUG: ow_ftdi.c:(484) ftdi_write: 1 = actual 1 DEBUG: ow_ftdi.c:(484) ftdi_write: 1 = actual 1 DEBUG: ow_link.c:(431) Checking LINK version DEBUG: ow_ftdi.c:(402) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_ftdi.c:(463) ftdi_read: 1 - 0 = 1 (2 retries) ... DEBUG: ow_link.c:(218) Link version is unrecognized: LinkUSB V1.7 (but that's ok). DEBUG: ow_net_server.c:(76) ServerAddr: [0.0.0.0] [4304] / So, again, thank you Johan for pointing out the detail with the ftdi addressing scheme, which got me building from source which solved the problem for me. Of course, it does not explain why the access as serial device without ftdi fails. But maybe thats a moot point, since you might as well access it in emulated DS2408B-mode, which works fine. Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link
On 25/07/17 20:16, Martin Patzak (GMX) wrote: > > > > On 07/25/17 15:36, Marcus Priesch wrote: >> ... >> no, i dont see any extra things you need when talking to a linkusb in >> native mode - it's also ascii, however maybe thats implemented >> differently in owfs, because configure says something about using >> libftdi for linkusb support - however, i have support compiled in. > thanks for making the effort and checking this... > I found on the github owfs site: > > /libftdi must be installed to use //LinkUSB > / > which I have installed... otherwise you would get an error. > > Main reason for using the --link option would be the increased > performance by factor 2! Not 100% correct. LinkUSB can be used through regular serial device just fine without libftdi & libusb. However, if owfs is built with libftdi and it is used instead of using a serial tty, the performance is improved as Martin writes. With "--link=/dev/ttyUSB0" it would access it as serial device (no ftdi required). With "--link=ftdi:XXX (XXX as per man page) it would use libftdi for direct communication. You could also try "--device=/dev/ttyUSB0" to use in "emulated DS2408B-mode" As to why it is not working, no idea. It can apparently read the version, so some kind of communication is working. As for the message "Link version is unrecognized: LinkUSB V1.7 (but that's ok).", there might be some changes in 1.7 which owfs does not know about. I took a (very) quick look at the latest "The Link Family Manual" [1], but didn't find anything specific about 1.7. Might very well have missed something though. Regards Johan 1. https://www.ibuttonlink.com/pages/information -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link
On 07/25/17 15:36, Marcus Priesch wrote: ... i just tried 3.2_p1 on gentoo - via custom ebuild, but no success either well, thats too bad... thanks for testing it though. i took a quick look on the code, but could not find anything useful, despite the fact that link recognition ends at version 1.5 - where the switch statement sets adapter type to LINK_15, but this never gets cought somewhere ... at least i didnt find it ... Yes, I don't think it's related to the version of the LinkUSB. Firstly, the debug message tells us so: / Link version is unrecognized: LinkUSB V1.7 (but that's ok). :-)// / And secondly, it does not work with a LinkUSB V1.4 either... :-( ... no, i dont see any extra things you need when talking to a linkusb in native mode - it's also ascii, however maybe thats implemented differently in owfs, because configure says something about using libftdi for linkusb support - however, i have support compiled in. thanks for making the effort and checking this... I found on the github owfs site: /libftdi must be installed to use //LinkUSB / which I have installed... otherwise you would get an error. Main reason for using the --link option would be the increased performance by factor 2! Cheerio, Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link
Hello Martin, Am 2017-07-25 um 13:37 schrieb Martin Patzak (GMX): > Do you compile 3.2p1 yourself. The newest package for Debian and Raspi > is 3.1p5, which is what I am using. i just tried 3.2_p1 on gentoo - via custom ebuild, but no success either i took a quick look on the code, but could not find anything useful, despite the fact that link recognition ends at version 1.5 - where the switch statement sets adapter type to LINK_15, but this never gets cought somewhere ... at least i didnt find it ... i suspect some code maybe magically has vanished ... are there regression tests with linkusbs ? > I suspect that people using the /--link/ option are using a > self-compiled owserver, which would explain why you can confirm my problem. > > Is there an option that was maybe not compiled in the Debian package of > owserver that might be need to make this work? I wonder... no, i dont see any extra things you need when talking to a linkusb in native mode - it's also ascii, however maybe thats implemented differently in owfs, because configure says something about using libftdi for linkusb support - however, i have support compiled in. so i think we need help from the devs ... PPUL ;))) regards, marcus. > > Servus, > Martin > > > On 07/25/17 12:32, Marcus Priesch wrote: >> Hello Martin, >> >> >>> ... /same lines//repeat a while/ >>> DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds >>> DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 >>> DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds >>> DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 >>> DEBUG: ow_link.c:(218) Link version is unrecognized: LinkUSB V1.7 (but >>> that's ok). >>> CONNECT: owlib.c:(216) Cannot open LINK bus master at /dev/ttyUSB0 >>> ... /cleaning up and ending/ >> i can confirm this with LinkUSB V1.7 and owfs 3.1p4 - will try current >> 3.2p1 next ... >> >> regards, >> marcus. >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> Owfs-developers mailing list >> Owfs-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/owfs-developers >> > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > ___ > Owfs-developers mailing list > Owfs-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/owfs-developers > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link
Hi Marcus, thank you for confirming. I tried quite a while in different variations... no success. Do you compile 3.2p1 yourself. The newest package for Debian and Raspi is 3.1p5, which is what I am using. I suspect that people using the /--link/ option are using a self-compiled owserver, which would explain why you can confirm my problem. Is there an option that was maybe not compiled in the Debian package of owserver that might be need to make this work? I wonder... Servus, Martin On 07/25/17 12:32, Marcus Priesch wrote: Hello Martin, ... /same lines//repeat a while/ DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_link.c:(218) Link version is unrecognized: LinkUSB V1.7 (but that's ok). CONNECT: owlib.c:(216) Cannot open LINK bus master at /dev/ttyUSB0 ... /cleaning up and ending/ i can confirm this with LinkUSB V1.7 and owfs 3.1p4 - will try current 3.2p1 next ... regards, marcus. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link
Hello Martin, > ... /same lines//repeat a while/ > DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds > DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 > DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds > DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 > DEBUG: ow_link.c:(218) Link version is unrecognized: LinkUSB V1.7 (but > that's ok). > CONNECT: owlib.c:(216) Cannot open LINK bus master at /dev/ttyUSB0 > ... /cleaning up and ending/ i can confirm this with LinkUSB V1.7 and owfs 3.1p4 - will try current 3.2p1 next ... regards, marcus. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
[Owfs-developers] problems starting owserver on a LinkUSB with option link
Hello all, I am trying to start owserver with a LinkUSB V 1.7 as bus master using the option /--link/. I am able to start owserver with the LinkUSB V 1.7 and V 1.4 using the option "d" for device without any problems. I am experiencing the same problems on a Raspi with both LinkUSB V 1.4 and V 1.7 when using the option /--link/, while the option "d" works fine as well here is an excerpt of the log: mnm@vincent:~$ sudo owserver --link=/dev/ttyUSB0 --debug DEBUG MODE libow version: 3.1p5 DEBUG: ow_daemon.c:(170) main thread id = 140041592982720 DEBUG: ow_inotify.c:(80) No configuration files to monitor CONNECT: ow_dnssd.c:(81) Zeroconf/Bonjour is disabled since dnssd library isn't found CALL: ow_parsename.c:(104) path=[] DEBUG: owlib.c:(77) Global temp limit 0C to 100C (for fake and mock adapters) DEBUG: ow_com.c:(47) Auto initialization of /dev/ttyUSB0 DEBUG: ow_link.c:(328) Detecting serial LINK using 9600 bps DEBUG: ow_link.c:(360) Slurp in initial bytes DEBUG: ow_link.c:(431) Checking LINK version DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds ... /same lines//repeat a while/ DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(63) attempt 1 bytes Time: 1.00 seconds DEBUG: ow_tcp_read.c:(113) read: 1 - 0 = 1 DEBUG: ow_link.c:(218) Link version is unrecognized: LinkUSB V1.7 (but that's ok). CONNECT: owlib.c:(216) Cannot open LINK bus master at /dev/ttyUSB0 ... /cleaning up and ending/ What seams to be the problem? Anybody seen this before? Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
