Re: [Owfs-developers] git pull returns 502 error message

[Martin Patzak (GMX)]

> Fortunately, a while back I setup a mirror on Github,
> https://github.com/owfs/owfs, which is (or at least attempts to be)
> synced every 15 minutes.
> This can be used for read access when sourceforge is unreachable.
>
> Also, so far we've actually had 2 pull requests coming in through GH!
I was one of those two! Who was the other on, I wonder? ;-)

But, I think it's habit, that people use sf over github for owfs...
>
> Regards
> 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


--
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

[Martin Patzak (GMX)]

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

[Martin Patzak (GMX)]

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
   DEBU

Re: [Owfs-developers] problems starting owserver on a LinkUSB with option link

[Martin Patzak (GMX)]

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

[Owfs-developers] Fwd: Re: problems starting owserver on a LinkUSB with option link

[Martin Patzak (GMX)]

sorry, forgot to hit 'reply all'... again ;-)


 Forwarded Message 
Subject: 	Re: [Owfs-developers] problems starting owserver on a LinkUSB 
with option link

Date:   Sun, 13 Aug 2017 10:42:19 +0200
From:   Martin Patzak (GMX) <martin.pat...@gmx.de>
To: Hans-Frieder Vogt <hfv...@gmx.net>





On 08.08.2017 22:59, Hans-Frieder Vogt wrote:

 Hi all,

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


I did apply your patch, and it is working fine. I compiled git-source 
owfs 3.2p1 for platform amd64 on an x86_64 machine and for platform 
armvh on an armv7l machine.


Then I tested on both machines with a LinkUSB V1.4 and V1.7 starting 
owserver with and without '--debug' and the following three adapter options:


   --link=/dev/ttyUSB - success, was not working 
before patch, works fine now
--link=ftdi:s::: - success, was working, 
still works with patch applied
-d /dev/ttyUSB - success, was working, still works with patch 
applied


Thank You again for sharing the patch,

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

[Owfs-developers] Fwd: Re: Problem starting owserver on a LinkUSB with option ftdi addressing without sudo

[Martin Patzak (GMX)]

sorry, forgot to hit 'reply all'...


 Forwarded Message 
Subject: 	Re: [Owfs-developers] Problem starting owserver on a LinkUSB 
with option ftdi addressing without sudo

Date:   Thu, 10 Aug 2017 19:01:07 +0200
From:   Martin Patzak (GMX) <martin.pat...@gmx.de>
To: Eloy Paris <pe...@chapus.net>





On 10.08.2017 18:06, Eloy Paris wrote:

Hi Martin,

On Thu, Aug 10, 2017 at 03:22:19PM +0200, Martin Patzak (GMX) wrote:

[...]


A small enhancement that you can add and use is to have udevd create
a predictable symlink for the device. This way if you plug in more
USB devices, or plug things in a different order so they get assigned
the same /dev/ node that your LinkUSB currently has, your owserver or
whatever programs use your LinkUSB will still be able to find it.

As an example, here's what I have on my
/etc/udev/rules.d/50-local-usb-serial.rules file:

--
#
# 
Fromhttp://marc.merlins.org/perso/linuxha/2010-06.html#Dealing-with-many-USB-to-Serial-Port-Converters-on-linux-and-device-naming
#
# After making a change 'udevadm trigger' will update symlinks.
#

#http://www.reactivated.net/writing_udev_rules.html#udevinfo
# was udevinfo -a -p /class/tty/ttyUSB0
# now udevadm info --attribute-walk -p /class/tty/ttyUSB0
# (used to determine product ID, serial number, etc. to be used
# in the declarations below)

SUBSYSTEMS=="usb", ATTRS{product}=="FT232R USB UART", ATTRS{serial}=="A5008b6u", 
SYMLINK+="plm"
SUBSYSTEMS=="usb", ATTRS{product}=="FT232R USB UART", ATTRS{serial}=="A400bXjP", 
SYMLINK+="1wire-master0"
SUBSYSTEMS=="usb", ATTRS{product}=="FT232R USB UART", ATTRS{serial}=="A800eIPR", 
SYMLINK+="1wire-master1"
SUBSYSTEMS=="usb", ATTRS{product}=="FT231X USB UART", ATTRS{serial}=="DC00HJ03", 
SYMLINK+="moteino-usb"
--

These rules will create the symlinks /dev/plm, /dev/1wire-master0,
/dev/1wire-master1, and /dev/moteino-usb for the FTDI serial-to-USB
chips with those serial numbers. Applications (like owserver) then
use the symlinks instead of the actual /dev/bus/usb// path. For
example, my /etc/owfs.conf contains this:

server: device = /dev/1wire-master0

Cheers,

Eloy Paris.-

Hello Eloy,

thanks for your suggestion. I had a rule just like yours, but it was 
linked to the usb-serial device /dev/ttyUSB and not /dev/bus/usb//.

Can you please check, where your symlink actually points to?

But regardless, I recently learned, that in order to get direct ftdi 
communication in owserver, on has to address the device in a special 
way: ftdi:..., in my case, a LinkUSB, it looks like:


/owserver --link=ftdi:s:0x0403:0x6001:A800bXHr/

so i cannot use a symlink as address. But this way of addressing is also 
unique, because the serial number is also given, when using the option 
's:' (for serial number)


If you address the serial usb device, you only get native serial 
communication, like so


/owserver --link=/dev/ttyUSB

/this is what I did in the beginning, and here you could use your 
symlink, but you won't get the speed advantage of direct communication, 
as Johan explained to me.


My problem then was, that I could only start owserver in direct 
communication mode, when I used 'sudo'. I did not know which node I have 
change the permission on in order to get owserver started. Matthias 
pointed out, that I have to talk to the raw usb device, which I then 
found resides in /dev/bus/usb//, which is created by udev. Well 
there is a corresponding raw device created by SYSFS in 
/sys/platform/bla/bla/bla/deep/down/there, which also Matthias pointed 
out, but you don't have to bother with that.


Cheers,

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] Problem starting owserver on a LinkUSB with option ftdi addressing without sudo

[Martin Patzak (GMX)]

On 09.08.2017 22:14, Matthias Urlichs via Owfs-developers wrote:

Hello,

(b) with an additional DRIVER=="USB" condition.


This is nonsense; the "USB" needs to be lowercase and the field is named
DRIVERS. Sorry about that.


Good news everyone, it works! Marvelous, special thanks to Matthias and 
to Johan to solve this issue :-)


Only so much, the working rule now looks like (at the moment, might 
change soon ;-) ):


SUBSYSTEMS=="usb", DRIVERS=="usb", ATTRS{manufacturer}=="FTDI", 
ATTRS{product}=="FT232R USB UART", ATTRS{serial}=="A800bXHr", 
GROUP="owsrv", MODE="0664"


This rule results in a node residing in /dev/bus/usb// which is 
read and writeable by the group owsrv , in my case it looks at the 
moment like


/ls -al /dev/bus/usb/003///
//...//
//crw-rw-r-- 1 root owsrv 189, 261 Aug 10 15:07 006/

owserver then accessess this node without sudo, in ftdi addressing 
scheme to use direct communication.



BUT more good news, and contrary to my previous statement: "One 'S' too 
little can make or brake the rule...", it DOES work without all the S's too!


SUBSYSTEM=="usb", DRIVER=="usb", ATTR{manufacturer}=="FTDI", 
ATTR{product}=="FT232R USB UART", ATTR{serial}=="A800bXHr", 
GROUP="owsrv", MODE="0664"


The answer for the confusion (on the net) is, that parent devices share 
attributes, that get the key ATTRS  - I will show this in a different 
post in the future.


Again thanks guys, for your help! But, this isn't over ;-)

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] Problem starting owserver on a LinkUSB with option ftdi addressing without sudo

[Martin Patzak (GMX)]

On 09.08.2017 22:14, Matthias Urlichs via Owfs-developers wrote:

Hello,

(b) with an additional DRIVER=="USB" condition.


This is nonsense; the "USB" needs to be lowercase and the field is named
DRIVERS. Sorry about that.
Good morning and thank you Matthias, for telling me right away - udev 
rules are particularly particular ;)

One 'S' too little can make or brake the rule...

Martin

P.S. I will try later, when I get a chance


--
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] Problem starting owserver on a LinkUSB with option ftdi addressing without sudo

[Martin Patzak (GMX)]

On 09.08.2017 20:49, Matthias Urlichs via Owfs-developers wrote:

On 09.08.2017 19:46, Martin Patzak (GMX) wrote:
SUBSYSTEMS=="usb", ATTRS{manufacturer}=="FTDI", 
ATTRS{product}=="FT232R USB UART", ATTRS{serial}=="A800bXHr", 
GROUP="owsrv", MODE="0664", SYMLINK+="LinkUSB"


For me this works perfectly (a) without the symlink (b) with an 
additional DRIVER=="USB" condition.


(a) symlinking doesn't work with USB bus entries.
(b) is required because you don't want to use the TTY. owserver needs 
to access the "raw" USB device, i.e. (in my case)

/sys/devices/platform/soc/2098.usb/usb1/1-1/1-1.3
instead of
/sys/devices/platform/soc/2098.usb/usb1/1-1/1-1.3/1-1.3\:1.0/tty/ttyACM0


Matthias, thank you for your swift and in-depth response.
For today I am udev-ed out! So I will try your changes to my rule tomorrow.

Meanwhile I was tinkering some more and I found the device node that 
owserver uses:


/ls -al /dev/bus/usb/003/017
crw-rw-r-- 1 root root 189, 272 Aug  9 21:05 017

/I changed the group of that node to 'owsrv' and owserver with ftdi:... 
does indeed start without sudo!


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

[Owfs-developers] Problem starting owserver on a LinkUSB with option ftdi addressing without sudo

[Martin Patzak (GMX)]

I am not able to start owserver without sudo on a LinkUSB with ftdi 
addressing.


I have an udev rule that works for owserver and the LinkUSB, creating a 
symbolic link to /dev/ttyUSB and setting the group to 'owsrv' and the 
mode to group can read/write /dev/ttyUSB looking like:


SUBSYSTEMS=="usb", ATTRS{manufacturer}=="FTDI", 
ATTRS{product}=="FT232R USB UART", ATTRS{serial}=="A800bXHr", 
GROUP="owsrv", MODE="0664", SYMLINK+="LinkUSB"


BUT since the owserver with ftdi addressing takes down ttyUSB, like 
syslog says:


/ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected 
from ttyUSB0

ftdi_sio 3-1.1:1.0: device disconnected/

(btw: it does not have the courtesy to put it back afterwards either ;) )

So, a different interface has to be used by owserver with ftdi direct 
communication and like Johan mentioned


"chown/chgrp some node in /dev/usb/something"

I check there first, but my /dev has no /usb directory, but it has a 
bunch of 'usbdevX' which lsusb tells me that usbdev3.17 is my LinkUSB:


/lsusb
...
Bus 003 Device 017: ID 0403:6001 Future Technology Devices 
International, Ltd FT232 USB-Serial (UART) IC

...
/
so, for test-purposes I changed the manually the group of usbdev3.17 to 
'owsrv' and added 'rw' for the group


/ls -al /dev/usbdev3.17
crw-rw 1 root owsrv 189, 272 Aug  8 19:48 /dev/usbdev3.17
/
but still owserver gives me 'permission denied' in the debug

/DEBUG MODE
libow version:
3.2p1
  DEBUG: ow_daemon.c:(170) main thread id = 3069509632
  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:s:0x0403:0x6001:A800bXHr
CONNECT: ow_ftdi.c:(213) [Permission denied] Failed to open FTDI device 
with description 's:0x0403:0x6001:A800bXHr': -4 = usb_open() failed

  DEBUG: ow_link.c:(328) Detecting ftdi LINK using 9600 bps
CONNECT: ow_ftdi.c:(213) [Permission denied] Failed to open FTDI device 
with description 's:0x0403:0x6001:A800bXHr': -4 = usb_open() failed

/...
CONNECT: owlib.c:(216) Cannot open LINK bus master at 
ftdi:s:0x0403:0x6001:A800bXHr

  DEBUG: ow_link.c:(857) LINK_close called on already closed connection
DEFAULT: owlib.c:(52) No valid 1-wire buses found

Question is: *which device is to change permissions and group, so 
owserver with a LinkUSB with ftdi addressing can be started without sudo?*

Next question ;)  what would the udev rule look like?



Sidenote: the keys of udev seem to change rather often. What was SYSFS 
years ago, seems now to be ATTRS.

I found, that a good way to check what udev knows about your device is:

/udevadm info -a -p $(udevadm info -q path -n ttyUSB0)/

the option -p expects a systempath, which I found rather hard to figure 
out, until I found the above solution, where the path /$(udevadm info -q 
path -n ttyUSB0) /rather cleverly is given by udevadm itself, which in 
my case results in:


//devices/platform/sw-ehci.2/usb3/3-1/3-1.1/3-1.1:1.0/ttyUSB0/tty/ttyUSB0/

but I have no idea where in the system this path exists. Is that only in 
udev-land or what?

I found the same info in

ls -al /sys/bus/usb-serial/devices/
...
lrwxrwxrwx 1 root root 0 Aug  9 19:36 ttyUSB0 -> 
../../../devices/platform/sw-ehci.2/usb3/3-1/3-1.1/3-1.1:1.0/ttyUSB0


and again where does this symlink point to? I don't know where it resides...

Sidenote 2: to get the ttyUSB back, once owserver took it down, 
instead of getting up, walking over to the actual device un- and 
re-plugging it, it is more efficient :) to unload and reload the 
ftdi_sio module:


sudo /rmmod ftdi_sio
sudo modprobe ftdi_sio


/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

[Martin Patzak (GMX)]

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

[Martin Patzak (GMX)]

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

[Martin Patzak (GMX)]

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

[Martin Patzak (GMX)]

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

[Martin Patzak (GMX)]

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

[Owfs-developers] problems starting owserver on a LinkUSB with option link

[Martin Patzak (GMX)]

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

Re: [Owfs-developers] Where to get LinkUSB in UK

[Martin Patzak (GMX)]

Fuchs is also delivering to the UK:

http://www.fuchs-shop.com/en/shop/shipping/


On 04/16/2017 12:04 PM, Colin Law wrote:

On 16 April 2017 at 10:40, Colin Law  wrote:

Does anyone know where I can get a LinkUSB in the UK? Homechip have
gone out of business apparently.  It is to replace a failed unit in a
working system so I would prefer a direct replacement if possible.

Or is it just that Homechip's website has gone AWOL?
www.homechip.com

Colin

--
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] FTDI problem on pi

[Martin Patzak (GMX)]

On 03/03/2017 10:02 AM, Colin Law wrote:
On 3 March 2017 at 08:42, Martin Patzak (GMX) <martin.pat...@gmx.de 
<mailto:martin.pat...@gmx.de>> wrote:


On 03/02/2017 08:50 PM, Colin Law wrote:
> It appears that the supplied version is not compiled with the
ftdi option.

how do you check for that? Why is the Debian package not compiled
with ftdi?


When I ran it I got
 OWFS[26316]: DEFAULT: ow_arg.c:(85) FTDI support not included in 
compilation. Use generic serial device.

which seemed suggestive.

ok, I see. And yes, it does seem suggestive :-)


No idea why it is not built with that, you would have to ask the 
packager I suppose.

I might have to do that then ;-)
Thanks Colin,

Martin


Colin




--
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] FTDI problem on pi

[Martin Patzak (GMX)]

On 03/02/2017 08:50 PM, Colin Law wrote:
> It appears that the supplied version is not compiled with the ftdi option.

how do you check for that? Why is the Debian package not compiled with ftdi?


--
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] DS18S20 temperature keeps jumping with owget

[Martin Patzak (GMX)]

looks like random values was owserver by an chance started with the fake 
parameter?



On 01/14/2017 09:06 PM, Rainer Dorsch wrote:


Hi,

I am wondering if anybody has seen this before: When I read 
temperature from a DS18S20, the value keeps jumping:


root@mohot:~# owget /10.67C6697351FF/type

DS18S20root@mohot:~#

root@mohot:~# owget /10.67C6697351FF/temperature

35.5571root@mohot:~# owget /10.67C6697351FF/temperature

36.9438root@mohot:~# owget /10.67C6697351FF/temperature

87.643root@mohot:~# owget /10.67C6697351FF/temperature

25.6785root@mohot:~# owget /10.67C6697351FF/temperature

65.7137root@mohot:~#

Any hint is welcome.

Many thanks

Rainer

--

Rainer Dorsch

http://bokomoko.de/



--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Problem with owhttpd on a raspberry pi (owfs-3.0p2)

[Martin Patzak (GMX)]

On 01/14/2017 02:33 PM, Ritchie wrote:
> Hi to All,
>
> I just reinstalled my raspberry Pi (1) with jessie.
>
> After that I installed the owserver owfs-3.0p2 from source code,
> because I guess this is the latest running version of owfs on raspberry
> pi without any problems so far.

there is no need to compile from source.
Just follow the advice Colin gave you already with this:

Install owfs from the 'testing' repository using the technique in
https://sourceforge.net/p/owfs/mailman/message/35357871/

Colin




--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owserver success reading 85C on node latesttemp

[Martin Patzak (GMX)]

On 12/09/2016 01:50 PM, Jan Kandziora wrote:
> Am 09.12.2016 um 12:20 schrieb Martin Patzak (GMX):
>> Hello all,
>>
>> with commit /c858e409ab7118f418b78afbae618d9b0f135700 /by Stefano
>> Miccoli reading a temperatur of 85C with use of /simultaneous/ and node
>> /l//atesttemp/ works as exspected.
>>
> Fine. I'll prepare the next release.
Excellent! Thank You!

Martin


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] issues building owfs from github source

[Martin Patzak (GMX)]

On 12/08/2016 06:53 PM, Martin Patzak (GMX) wrote:

On 12/08/2016 05:46 PM, Stefano Miccoli wrote:
   ...


to have files in /opt/owfs.

(BTW: I hate the idea of "$ sudo make install”: one should always 
first set up the /opt/owfs and then issue “make install” from an 
unprivileged user.)
Thanks for pointing this out. The only reason for sudo here would be 
the lack of write privileges to opt.

Another reason, why would want to install to my local /home directory...


Of course it turned out to be a bit more complex than that:
I ran into the problem that the systemd services would be set up also in 
a directory which my user has no write privileges.


Since I could not find how to disable the creation of the systemd 
services, I managed to re-route them to a local directory by running 
./configure with


/--with-systemdsystemunitdir=/some/other/local/dir/systemd

/The whole configure command turned out to look like

./configure --disable-swig --prefix=~/owfs/ --program-suffix=_test85C 
--with-systemdsystemunitdir=~/owfs/systemd


that beeing said, I managed finally to install the binaries into my 
local folder.


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] owserver success reading 85C on node latesttemp

[Martin Patzak (GMX)]

Hello all,

with commit /c858e409ab7118f418b78afbae618d9b0f135700 /by Stefano 
Miccoli reading a temperatur of 85C with use of /simultaneous/ and node 
/l//atesttemp/ works as exspected.

Excerpt from debug:

...
/  DEBUG: ow_read.c:(226) /28.AF531F06/latesttemp returns 12
  DEBUG: ow_read.c:(103) /28.AF531F06/latesttemp return 12
  DEBUG: read.c:(81) ReadHandler: FS_read_postparse read on 
/28.AF531F06/latesttemp return = 12

OWQ OneWireQuery structure of /28.AF531F06/latesttemp
OneWireQuery size=12 offset=0, extension=0
Byte buffer OneWireQuery buffer, length=12
--000: 20 20 20 20 20 20 20 20 20 20 38 35
*<  85>*
Cleanup = 0006OneWireQuery I=12 U=12 F=5.92879E-323 Y=12 D=Thu 
Jan  1 01:00:12 1970


--- OneWireQuery done
  DEBUG: read.c:(89) ReadHandler: FS_read_postparse ok size=12
  DEBUG: read.c:(100) ReadHandler: To Client cm->payload=12 cm->size=12 
cm->offset=0

Byte buffer Data returned to client, length=12
-- NULL buffer
  DEBUG: data.c:(146) Read message done value=0x7fb69c028e90
  DEBUG: ow_parsename.c:(63) /28.AF531F06/latesttemp
  DEBUG: data.c:(193) DataHandler: FS_ParsedName_destroy done
  DEBUG: data.c:(207) DataHandler: cm.ret=12
  DEBUG: to_client.c:(76) payload=12 size=12, ret=12, sg=0x0 offset=0
  DEBUG: data.c:(226) Finished with client request
  DEBUG: handler.c:(135) OWSERVER handler done
  DEBUG: ow_net_server.c:(259) Normal completion.
/
Thanks to everyone helping to change the behaviour of owserver reading a 
temperature of 85C.

Thats all folks!




owserver success reading 85C.tar.gz
Description: application/gzip
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] issues building owfs from github source

[Martin Patzak (GMX)]

On 12/08/2016 07:19 PM, Matthias Urlichs wrote:
> I didn't even know that you can change the default prefix. Oh well.
>
> On 08.12.2016 18:59, Martin Patzak (GMX) wrote:
>> how do I change it? The Google-Kugel is not so helpful there...
> How about using the --prefix=… option?
Thank you will do so.
I just found different and confusing information to --prefix, so I was 
not sure if it would be safe and sufficient to use it.


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] issues building owfs from github source

[Martin Patzak (GMX)]

On 12/08/2016 06:59 PM, Tomasz Torcz wrote:
> On Thu, Dec 08, 2016 at 06:53:57PM +0100, Martin Patzak (GMX) wrote:
>>
>> On 12/08/2016 05:46 PM, Stefano Miccoli wrote:
>>> In owfs, as per co the default prefix is /opt /owfs
>>>
>>> configure.ac:63:AC_PREFIX_DEFAULT(*/opt/owfs*)dnl
>> yes, it is the the default
>> how do I change it? The Google-Kugel is not so helpful there...
>Now need to google when you have answer at your fingertips.
> ./configure --help will tell you about PREFIX.
yes it does. Thank you!

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] issues building owfs from github source

[Martin Patzak (GMX)]

On 12/08/2016 05:46 PM, Stefano Miccoli wrote:

In owfs, as per co the default prefix is /opt /owfs

configure.ac:63:AC_PREFIX_DEFAULT(*/opt/owfs*)dnl

yes, it is the the default
how do I change it? The Google-Kugel is not so helpful there...

do I edit the configure script?

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] issues building owfs from github source

[Martin Patzak (GMX)]

On 12/08/2016 04:54 PM, Matthias Urlichs wrote:
> On 08.12.2016 16:34, Martin Patzak (GMX) wrote:
>>> As a quick fix, try
>>>
>>> $ ./configure --disable-swig
>> that worked, thanks!
>>
>> BUT: after it ran through without error, I do not find anything in /opt
>> there is no subdir /owfs? confused
> Why /opt? the default for "make install" is /usr/local, unless you
> configure a different prefix.
This is the directory given by ./configure

I googled to change it, e.g. to a my home test directory, but it looks 
like it is not so simple, so I left it to the default

>
>


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] issues building owfs from github source

[Martin Patzak (GMX)]

On 12/08/2016 05:46 PM, Stefano Miccoli wrote:

In owfs, as per co the default prefix is /opt /owfs

configure.ac:63:AC_PREFIX_DEFAULT(*/opt/owfs*)dnl

yes, it is the the default
how do I change it? The Google-Kugel is not so helpful there...


of cours you need a

$ make install

aha! Of course, install would be a good idea.
The last line in ./bootstrap is to do now do a .//configure/ and the a 
/make/, so I was mislead, that this would be it!


to have files in /opt/owfs.

(BTW: I hate the idea of "$ sudo make install”: one should always 
first set up the /opt/owfs and then issue “make install” from an 
unprivileged user.)
Thanks for pointing this out. The only reason for sudo here would be the 
lack of write privileges to opt.

Another reason, why would want to install to my local /home directory...

Thank You!



As what regards SWIG, in my opinion all the OWLIB language bindings 
should be disabled by default, in order to encourage the use of the 
OWNET clients.


If I can add a personal wish-list of changes to OWFS:

1) migrate the source on github
2) review configure.ac in order to disable most of the OWLIB language 
bindings

3) clean-up a lot of apparently dead code (e.g. src/rpm)

S.

On 08 Dec 2016, at 16:54, Matthias Urlichs <matth...@urlichs.de 
<mailto:matth...@urlichs.de>> wrote:


On 08.12.2016 16:34, Martin Patzak (GMX) wrote:

As a quick fix, try

$ ./configure --disable-swig

that worked, thanks!

BUT: after it ran through without error, I do not find anything in /opt
there is no subdir /owfs? confused

Why /opt? the default for "make install" is /usr/local, unless you
configure a different prefix.


--
-- Matthias Urlichs


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net 
<mailto:Owfs-developers@lists.sourceforge.net>

https://lists.sourceforge.net/lists/listinfo/owfs-developers




--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] issues building owfs from github source

[Martin Patzak (GMX)]

> As a quick fix, try
>
> $ ./configure --disable-swig
that worked, thanks!

BUT: after it ran through without error, I do not find anything in /opt
there is no subdir /owfs? confused

I do not build very often, so I am sorry to have to ask those questions

Martin



--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] issues building owfs from github source

[Martin Patzak (GMX)]

Hello all,

I am trying to build the latest owfs from github (and I thought this was 
the easy part ;) - building it as a debian package for the ARM platform 
will surely proofe to be harder still)


What I did so far:

/git clone git://git.code.sf.net/p/owfs/code owfs-code/
/
//cd owfs-code/

/.///bootstrap//
//... (output seems fine see attachment)/

/./configure/
/... (output seems fine see attachment)//
//
make/
/...//(for complete output see attachment)//

/... after a while this happens:

/Making all in php
make[3]: Entering directory '/home/mnm/git/owfs/owfs-code/module/swig/php'
  CC   ow_wrap.lo
ow_wrap.c:706:18: fatal error: zend.h: No such file or directory
 #include "zend.h"
  ^
compilation terminated.
Makefile:590: recipe for target 'ow_wrap.lo' failed
make[3]: *** [ow_wrap.lo] Error 1
make[3]: Leaving directory '/home/mnm/git/owfs/owfs-code/module/swig/php'
Makefile:501: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/mnm/git/owfs/owfs-code/module/swig'
Makefile:511: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/mnm/git/owfs/owfs-code/module'
Makefile:566: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
/

What could be the cause of this error?

Cheers Martin



error building owfs github 20161208.tar.gz
Description: application/gzip
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Problem reading temperatures of 85 degree Celsius

[Martin Patzak (GMX)]

On 12/06/2016 11:02 PM, Jan Kandziora wrote:
> Am 06.12.2016 um 12:13 schrieb Martin Patzak (GMX):
>>> Yes please.
>> ok will do on the weekend the latest. Which error-level should I apply?
>>
> Please update to the latest version in the git archive first, or apply
> Stefano's patch.
Ok, will try to do so and report back

Martin


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Problem reading temperatures of 85 degree Celsius

[Martin Patzak (GMX)]

On 12/06/2016 01:45 PM, Johan Ström wrote:
> On 06/12/16 13:38, Martin Patzak (GMX) wrote:
>>> By using the /latesttemp mentioned earlier, you only perform the read,
>>> and should thus not suffer from timeouts (given that the bus is not
>>> already backed up with previous queries).
>>> Note that a convert must always be triggered by using the
>>> /simultaneous/temperature endpoint before.
>> yes, I do exactly as you say, but cannot read a 85 degC value!
>> Why is it only me??? Others seem to read 85 degC fine
>>
>> Is anybody with a LinkUSB able to read 85 degC?
> Based on the diff posted by Stefano 2h ago, it looks like it actually
> rejects any 85 readings (invalidly, if I've understood everything
> correct). So that should probably be patched, then it should work as
> expected.
I am glad, it is NOT only me then...
>>> At least this is my understanding of it, I have not used latesttemp
>>> myself.. :)
>>> But as was mentioned by before, 85C is usually due to bad wiring/too low
>>> power... Powered sensors ftw :)
>> well, in my case I have real 85 degC the wiring and power-supply is ok.
> Well, that is of course another valid reason to get 85C.. :)
yes indeed it is :)



--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Problem reading temperatures of 85 degree Celsius

[Martin Patzak (GMX)]

On 12/06/2016 12:19 PM, Johan Ström wrote:
> On 06/12/16 12:07, Martin Patzak (GMX) wrote:
>> On 12/06/2016 11:31 AM, Colin Law wrote:
>>> In my code (in a node-red environment) if I get a value of 85 then I
>>> retry after a timeout (1 sec I think) and only if I get three 85 in a
>>> row do I accept it as 85.
>> my problem is, that I cannot read a value 85 degC at all, I do however
>> get error messages or time-outs, depending...
> When reading /temperature of a DS18x20, and the sensor returns 85, the
> owfs code will perform a re-read (including convert) up to 3 times in
> total. With 1s timeout, that will always be too short, and the client
> will timeout. Note that a client-side timeout does not abort the already
> issued query; if you called /temperature it will still try to
> convert+read 3 times, even if your client aborts after 1s. An
> immediately following query with 1s timeout may thus fail as well (since
> it just waits for the bus > 1s)
thank you for explaining the inner workings of owserver.
It sure looked like re-trying from my client-side.

I do drop this sensor and move on to the next one, when a read time-outs.
I do get then sometimes, subsequent error on one or two of the following 
sensors, which could be caused like you say, that owserver of course 
keeps retrying.
>
> By using the /latesttemp mentioned earlier, you only perform the read,
> and should thus not suffer from timeouts (given that the bus is not
> already backed up with previous queries).
> Note that a convert must always be triggered by using the
> /simultaneous/temperature endpoint before.
yes, I do exactly as you say, but cannot read a 85 degC value!
Why is it only me??? Others seem to read 85 degC fine

Is anybody with a LinkUSB able to read 85 degC?

>
> At least this is my understanding of it, I have not used latesttemp
> myself.. :)
> But as was mentioned by before, 85C is usually due to bad wiring/too low
> power... Powered sensors ftw :)
well, in my case I have real 85 degC the wiring and power-supply is ok.

Johan, thank You for Your thoughts

Martin


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Problem reading temperatures of 85 degree Celsius

[Martin Patzak (GMX)]

Unfortunately without any other error flag! That's why I
implemented a way to accept a temperature of 85.0 only, if the previously
read temp was in that range (82-88), otherwise I just skip this reading and
try once again.


This is exactly what owfs does and what leads to this error.

Currently I'm in favor of throwing all that 85°C "fixup" code out of
owfs completely. If there's an error in your electrical setup, you have
to fix it there, not by throwing more and more software workarounds at it.

*LIKE*

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Problem reading temperatures of 85 degree Celsius

[Martin Patzak (GMX)]

On 12/06/2016 11:31 AM, Colin Law wrote:
> In my code (in a node-red environment) if I get a value of 85 then I
> retry after a timeout (1 sec I think) and only if I get three 85 in a
> row do I accept it as 85.
my problem is, that I cannot read a value 85 degC at all, I do however 
get error messages or time-outs, depending...

Thank You for your input

Martin


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Problem reading temperatures of 85 degree Celsius

[Martin Patzak (GMX)]

On 12/06/2016 01:41 AM, Jan Kandziora wrote:
> Am 05.12.2016 um 09:35 schrieb Martin Patzak (GMX):
>>> The new node works fine too, but unfortunately I get an error, when a
>>> sensor is right at 85 deg C:
>>>
>>>
>>> /Traceback (most recent call last)://
>>> //  File "read_a_temp.py", line 15, in //
>>> //sensed = op.read('/28.676A2006/latesttemp')//
>>> //  File "/home/mnm/pyownet/src/pyownet/protocol.py", line 545, in read//
>>> //raise OwnetError(-ret, self.errmess[-ret], path)//
>>> //pyownet.protocol.OwnetError: [Errno 22] legacy - Invalid
>>> transaction: '/28.676A2006/latesttemp'
>>> /
>> hold on, my test was done in a rush, so I forgot to stop the task
>> reading the temps from the temperature node.
>> Could that have anything to do with error message?
>>
>> I cant test more today, because that was the last sensor over 85 deg C,
>> so I have to wait until tomorrow morning...
>>
> Please confirm that you can repeat the error condition first.
yes, I could repeat it today. This time I stopped first the other task 
reading the temperature nodes.
I cannot read a straight value of 85 degC, instead I get this 
transaction error. The values I can read are just above or just below 85 
degC.

I can provide debug from owserver if it would help you figuring out 
whats going on. Please advise.

You mentionened the manuals recieved an update regarding the new 
latesttemp node. I am sorry to ask this, but where do I find this. I did 
update owfs-doc to 3.1p4 but cannot find latesttemp anywhere. Is it 
somewhere else I should be looking?

Martin


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Problem reading temperatures of 85 degree Celsius

[Martin Patzak (GMX)]

On 12/05/2016 06:29 PM, Stefano Miccoli wrote:


On 05 Dec 2016, at 18:11, Martin Patzak (GMX) <martin.pat...@gmx.de 
<mailto:martin.pat...@gmx.de>> wrote:


/[Errno 1] Startup - command line parameters invalid: 
'28.CF791502/temperature'


/but this is rare, so I thought I better not mention it right now - 
but hey, now I did;-)


this error, despite it’s misleading description, occurs when you try 
to read a non present owfs node. In your case this means that the 
sensors has temporarily disappeared from the bus… (I experienced this, 
but usually this is not a problem, since it is sufficient to retry the 
read.)
yes, retrying helps. I wonder if this is software? But where? It is rare 
enough, and so I ignored it for now.


Stefano, thanks for sharing!

Martin



--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Problem reading temperatures of 85 degree Celsius

[Martin Patzak (GMX)]

On 12/05/2016 05:42 PM, Stefano Miccoli wrote:


On 05 Dec 2016, at 09:35, Martin Patzak (GMX) <martin.pat...@gmx.de 
<mailto:martin.pat...@gmx.de>> wrote:



The new node works fine too, but unfortunately I get an error, when 
a sensor is right at 85 deg C:



/Traceback (most recent call last)://
//  File "read_a_temp.py", line 15, in //
//sensed = op.read('/28.676A2006/latesttemp')//
//  File "/home/mnm/pyownet/src/pyownet/protocol.py", line 545, in 
read//

//raise OwnetError(-ret, self.errmess[-ret], path)//
//pyownet.protocol.OwnetError: [Errno 22] legacy - Invalid 
transaction: '/28.676A2006/latesttemp'

/


hold on, my test was done in a rush, so I forgot to stop the task 
reading the temps from the temperature node.

Could that have anything to do with error message?


As long as you have a single owserver process running, there can be 
any number of concurrent clients, or even concurrent access via the 
same pyownet.protocol.proxy object from different threads… I do not 
think this is the problem.

yes, I can confirm, I do use concurrent clients and never had problems.
I was more-so thinking, that owserver might take a sensor 'offline' or 
something like that, when a value of exactly 85 deg C is read. When I 
then at that time try to read that sensor it might come to this strange 
error???




BTW, pyownet.protocol.OwnetError simply reports the owserver error 
number (in this case 22) along with the error description available 
from /settings/return_codes/text.ALL (in this case "legacy - Invalid 
transaction”) and the path that caused the error.

I do get sometimes
/
[Errno 1] Startup - command line parameters invalid: 
'28.CF791502/temperature'


/but this is rare, so I thought I better not mention it right now - but 
hey, now I did ;-)




Me too, I’ve never experienced a 22 error: we need the help of a owfs 
wizard.

Yes, let's see what our 'Wizard of OWFS' (aka Jan) has to say to this.

Martin
--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Problem reading temperatures of 85 degree Celsius

[Martin Patzak (GMX)]

The new node works fine too, but unfortunately I get an error, when a 
sensor is right at 85 deg C:



/Traceback (most recent call last)://
//  File "read_a_temp.py", line 15, in //
//sensed = op.read('/28.676A2006/latesttemp')//
//  File "/home/mnm/pyownet/src/pyownet/protocol.py", line 545, in read//
//raise OwnetError(-ret, self.errmess[-ret], path)//
//pyownet.protocol.OwnetError: [Errno 22] legacy - Invalid 
transaction: '/28.676A2006/latesttemp'

/


hold on, my test was done in a rush, so I forgot to stop the task 
reading the temps from the temperature node.

Could that have anything to do with error message?

I cant test more today, because that was the last sensor over 85 deg C, 
so I have to wait until tomorrow morning...



--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Problem reading temperatures of 85 degree Celsius

[Martin Patzak (GMX)]

Hello Jan,

thanks for the swift and in-depth reply to my problem:

On 12/04/2016 07:31 PM, Jan Kandziora wrote:

Am 04.12.2016 um 12:07 schrieb Martin Patzak (GMX):

I am experiencing delays and also time-outs when reading temperatures of
very very close to and equal to 85 degrees Celsius.


This is a complicated situation as 85°C is the default power-up value
the sensor uses. When you have power failures during the conversion, you
cannot tell it apart from a valid 85°C reading.


Oh, I see

My application is a heating system, where a wood burning oven heats up
two 800l buffer containers of water to a max temperature of 95 degree
Celsius.

Every 30s simultaneous is written, followed by a two second wait, before
starting reading back the temperatures sequentially.


Please update to owfs-3.1p4. It has a new "latesttemp" node, which is
meant for exactly this setup. Trigger simulatenous/temperature, wait a
second in your user program, then read all the temperature values
sampled from the "latesttemp" node.
Thanks for pointing out, that there are changes in the latest version, 
that a relevant to the problem.
So, I did update, and gave it a try with simple testprogramm accessing 
the latesttemp node.
For testing I read only two sensors. First the one that is close to 85 
deg C and another one just for seeing the next read done.


The new node works fine too, but unfortunately I get an error, when a 
sensor is right at 85 deg C:



/Traceback (most recent call last)://
//  File "read_a_temp.py", line 15, in //
//sensed = op.read('/28.676A2006/latesttemp')//
//  File "/home/mnm/pyownet/src/pyownet/protocol.py", line 545, in read//
//raise OwnetError(-ret, self.errmess[-ret], path)//
//pyownet.protocol.OwnetError: [Errno 22] legacy - Invalid transaction: 
'/28.676A2006/latesttemp'


/here is the python test-code:

/import time//
//from pyownet import protocol//
//
//op = protocol.proxy("razmaban",port=4304)//
//
//
//op.write('/simultaneous/temperature', '1')//
//
//time.sleep(1)   # give the sensors time to convert their temps//
//
//print 'reading now...'//
//
//sensed = op.read('/28.676A2006/latesttemp')//
//print sensed//
//
//sensed = op.read('/28.DD591502/latesttemp')//
//print sensed//
//
/


First time I have seen this error message, what does it mean?





I am aware that the 18S20 did report an error with 85 deg C, but the
18B20 should not do this.

Is there something in owfs that would re-read in case a value of exactly
85 deg C would be returned by a sensor?


Yes, there is a try-again-mechanism when you read the "temperature" and
"temperatureXX" nodes. Update and use "latesttemp" instead.

Please see the updated manpages, too.
I did install owfs-doc 3.1p4, but I searched for 'latesttemp' and for 
'simultaneous', but I couldn't find anything.

Where do I find the updated information?

Cheers Martin

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] Problem reading temperatures of 85 degree Celsius

[Martin Patzak (GMX)]

Hello OWFS-developers,

I am experiencing delays and also time-outs when reading temperatures of 
very very close to and equal to 85 degrees Celsius.


I am using a BananaPI with a LinkUSB as hardware.

As software I am using on the system side owserver 3.1p1-6 and on the 
application side python together with pyownet as client to owserver.


I have 25 DS18B20, which are powered.

My application is a heating system, where a wood burning oven heats up 
two 800l buffer containers of water to a max temperature of 95 degree 
Celsius.


Every 30s simultaneous is written, followed by a two second wait, before 
starting reading back the temperatures sequentially. The time for an 
average read of one sensor is about 0.2 seconds at maximum resolution. I 
am monitoring the time of each read and when the read exceeds 0.25 
seconds I log this.
Additionally every read I do with pyownet is used with a time-out of 1s, 
meaning, if after 1 second owserver did not reply a value, I abort and 
go to the next sensor.


When the buffers get slowly discharged, the temperature of the sensors 
at the buffers slowly drifts to the 85 degree mark.


*Here is the thing**:*

While slowly drifting towards the 85 deg C mark, at first the sensor 
takes longer to read. The read time is then typically around 0.75s. That 
happens for a couple of cycles, before then the reading times out - 
longer than 1s, in which case the read is aborted and the next sensor 
gets read. It can alternate between time-out and elongated reading time. 
When a temperature is read, it is 85.0 something or later 84.9 
something. After a while the reading is back with longer reads, Finally 
everything is back to normal and the temperature is below 85 degrees C.


That happens successively for all the 10 sensor (5 at each buffer in 
various hights) .


I am aware that the 18S20 did report an error with 85 deg C, but the 
18B20 should not do this.


Is there something in owfs that would re-read in case a value of exactly 
85 deg C would be returned by a sensor?


Or is it the LinkUSB that is the culprit.

Does anybody else experience the same phenomenon?

Cheers 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] Can the owserver be "overloaded"?

[Martin Patzak (GMX)]

On 11/28/2016 03:33 PM, Arne Raaen wrote:
> Hi,
>
> I think what Jan explained is that DS2408 itself accepts only the full
> byte.
>
> So when you write a single PIO, owserver does the caching and rewrites
> the whole byte
I did understand, what Jan meant, but did not understand why I never 
seen a random switching of outputs for 6 years! I am running the heating 
system of our house with it.
So if there is a problem in owfs buffering the bytes, what am I doing 
different to not see it?

>
> My basic setup is an Intel-based linux PC (several years old), running
> Ubuntou 16.04   with owserver from the package, 3.1p1.
> About 10 m cat-5 cable between the LinkUSB and the Hobbyboards card.
>
> I also tested a Raspberry 1B, with just a short cable between the
> LinkUSB and the Hobbyboards card, which may have improved the situation
> a little bit
I did run a Rasberry for a while and moved to BananaPi last year.
I as well use the LinkUSB, but I use a selfmade IO-board, which has 3 
DS2408 on it. 12 outputs and 12 inputs.

> (that's why I attempted to strengthen my ground line), but the problems
> persisted, perhaps at a lower rate.

My wiring is about 30m and I use only telephone cable.
The 12V and the 5V are externally powered. I do have the power (still) 
on the same cable together with the 1wire signals, but it seems to work 
ok - never touch a running system.

>
> Since I rewrote my code to only write when needed  (i.e. read owserver
> first and write only if there is change), I have seen no problems for
> almost 2 months.
I am curious what fixed the problem: the reduced rate of writing or the 
reading inbetween.

I do a lot of reading as well: the task that communicates to the graphic 
display (HMI) of the heating system reads the IOs every second and the 
HMI gets updated accordingly.
One particular output gets written every second. It is an alive signal, 
indicating that software and bus are up and running. The signal switches 
an LED on and off and a relay switches on when the signal is not 
triggered for a while which in turn sounds a horn (it is in the cellar, 
so somebody can hear and react to it). The horn has not been heard of 
for quite a while ;)

Otherwise the outputs gets written only rarely: maybe 40 to 50 times in 
24 hours.

>
> That's why I naively thought "high traffic" might be the problem. But
> the way I interpret Jan, the failure in caching properly (although not
> understood) is not likely to be related to "overloading".

again, why don't I see this???

>
> That could still be consistent with my observations, I guess,  I have
> gone from 6x60x24 writes per day to a few.
>
> Apart from the HobbyBoards DS2408 I have  nearly 20 DS18B20 and a few
> DS2406, all parasitically powered, and a powered DS2450 on the bus.
On the same bus I have 25 powered DS18B20 which I read every 30 seconds 
after a simultaneous command.

>
>
> Arne
Thanks Arne for explaining your system more detailed. What does your 
system do?

Cheers Martin

>
>
>
>
>
>
>
>
>
> On 28.11.2016 09.30, Martin Patzak (GMX) wrote:
>> On 11/18/2016 08:11 PM, Jan Kandziora wrote:
>>> Am 18.11.2016 um 10:45 schrieb Arne Raaen:
>>>> Hi,
>>>>
>>>> I have a HobbyBoards relay card based on DS2408, used with LinkUSB
>>>>
>>>> I used a routine (unconditionally) updating PIO.0 through PIO.5 every
>>>> minute.
>>>>
>>>> I observed that PIO.6 and PIO.7 would be activated at random intervals,
>>>> typically a few times per day or less.
>>>>
>>> You cannot set single PIOs on the DS2408, owfs has to set them all as
>>> one. That's why owfs maintains the last state written to the PIO byte.
>>> As you found out the byte stored within owfs may be incorrect for
>>> circumstances we have yet to check.
>> Well, that is rather news to me. I do set single PIOs on two DS2408 in
>> my application.
>> I NEVER expirienced a problem with random switching IOs - I run my
>> heating system since 2010 with owfs, so I don't think I have been lucky
>> all this time ;)
>>
>> Would be interesting to know what exact system and environment the
>> random switching appears in.
>>
>> I can write up my system or answer more detailed questions if it might
>> help. Just ask.
>>
>> Cheers Martin
>>
>>> In the meantime, store the desired output pattern within your
>>> application and write PIO.ALL (or PIO.BYTE) instead of individual bits.
>>> That should make your problem go away immediately.
>>>
>>> Kind regards
>>>
>>> Jan
>>>
>>>
>>>
>>>
>>>
>>>
>

Re: [Owfs-developers] Can the owserver be "overloaded"?

[Martin Patzak (GMX)]

On 11/18/2016 08:11 PM, Jan Kandziora wrote:
> Am 18.11.2016 um 10:45 schrieb Arne Raaen:
>> Hi,
>>
>> I have a HobbyBoards relay card based on DS2408, used with LinkUSB
>>
>> I used a routine (unconditionally) updating PIO.0 through PIO.5 every
>> minute.
>>
>> I observed that PIO.6 and PIO.7 would be activated at random intervals,
>> typically a few times per day or less.
>>
> You cannot set single PIOs on the DS2408, owfs has to set them all as
> one. That's why owfs maintains the last state written to the PIO byte.
> As you found out the byte stored within owfs may be incorrect for
> circumstances we have yet to check.
Well, that is rather news to me. I do set single PIOs on two DS2408 in 
my application.
I NEVER expirienced a problem with random switching IOs - I run my 
heating system since 2010 with owfs, so I don't think I have been lucky 
all this time ;)

Would be interesting to know what exact system and environment the 
random switching appears in.

I can write up my system or answer more detailed questions if it might 
help. Just ask.

Cheers Martin

>
> In the meantime, store the desired output pattern within your
> application and write PIO.ALL (or PIO.BYTE) instead of individual bits.
> That should make your problem go away immediately.
>
> Kind regards
>
>   Jan
>
>
>
>
>
>
>
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Turning OWFS website into a Wiki. Was: owfs is DISABLED

[Martin Patzak (GMX)]

>
> If I had to decide, I would take all the content of the web site, throw
> out all the out-of-date information and feed the rest into a Mediawiki,
> where you and others can maintain it yourself. Then shutdown the old
> website.
>
>
> OWFS developers, OWFS users: should we do that?

Your idea is as contemporary as it is communal, so I, as an OWFS user, 
do think that this is an excellent suggestion!

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owfs is DISABLED

[Martin Patzak (GMX)]

who else thinks the following should find it's way onto the owfs web-site?
> BY THE WAY, why are you compiling yourself? Raspbian packages
> of owfs-3.1p1 are available.
>
> Edit (or create) your /etc/apt/preferences to contain:
> --
> Package: *
> Pin: release o=Raspbian,a=stable
> Pin-Priority: 500
>
> Package: *
> Pin: release o=Raspbian,a=testing
> Pin-Priority: 300
> --
> This is important so you keep stable (Jessie) for all packages but the ones
> explicitly taken from testing (Stretch).
>
>
> Then, add a line
> --
> deb http://mirrordirector.raspbian.org/raspbian/ testing main contrib 
> non-free rpi
> --
> to your /etc/apt/sources.list to get access to the Raspbian testing
> repository.
>
> Do an
>
> $ sudo apt-get update
>
> to read the package metadata, then check
>
> $ sudo apt-cache policy
>
> whether the testing repo is there with priority 300. Then
>
> $ sudo apt-get update -t testing owserver ow-shell
>
>
> Kind regards
>
>   Jan
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports.http://sdm.link/zohodev2dev
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owfs is DISABLED

[Martin Patzak (GMX)]

you just need to add write permission for your user or group to that 
directory to have the log written successfully,


and NO, NEVER build as superuser, like Jan already emphasized!


On 07/25/2016 07:59 PM, Mick Sulley wrote:

OK, so do I need to change a permission or do I need to run as sudo?


On 25/07/16 18:49, Roland Franke wrote:

Hello,


I am just building a test system to try out owshell and also installing
without sudo.
With  owfs-3.1p1 when I try ./configure I get
./configure: line 2256: config.log: Permission denied
./configure: line 2266: config.log: Permission denied

here will be the config.log written in the actually directory.
When you (User) not be the owner of that directory, this
fault appears.

Best regards,
Roland

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Concurrency issues?

[Martin Patzak (GMX)]

On 05/24/2016 07:01 PM, Andy Carter wrote:
> You are not alone wishing for an up to date debian/raspbian version, 
> however the various parts of 3.1p1-5 owfs are available from 
> http://archive.raspbian.org/raspbian/pool/main/o/owfs/
Hey Andy,

thanks for the link!

Cheers

Martin


--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Louis Swart LCD issues

[Martin Patzak (GMX)]

On 04/06/2016 09:43 AM, Andy Carter wrote:
>> The fact that a lot of distros lags behind is another problem though..
> debian stable particularly in my case which many use with perl based fhem :/
true, but you can easily install a newer version of owfs manually.
I did so a while ago myself and wrote a tiny howto on this list (if you 
can't find the post let me know, and I find it for you)

Cheers

Martin


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Getting simultaneous to work (and other)

[Martin Patzak (GMX)]

On 01/08/2016 01:07 AM, Stefano Miccoli wrote:


On 07 Jan 2016, at 14:45, Martin Patzak (GMX) <martin.pat...@gmx.de 
<mailto:martin.pat...@gmx.de>> wrote:


I am using the pyownet library to communicate to a local owserver.
I have 25 temp-sensors and 2 io 2408 modules on one powered bus with 
an usb-link as master.


I do use simultaneous to read all 25 sensors every 30 seconds as well 
(see below)
From a seperate task I am reading the state of the 1-wire IOs every 
second.
Another task lets a LED flash, that is connected to one of the 
Outputs, also every second (as an indicator of the state of the system)


The system runs 24/7 and is mainly busy running the heating system in 
our house.


I agree: since owserver is multi-threaded by design there is nothing 
wrong with multiple client tasks/threads accessing it concurrently. 
One should just avoid clogging the server wit an excessive number of 
requests.

ok good you can confirm that...



In this case it is the same sensor that takes longer to read in 
consequent reads for 7 times.
When a read takes longer, than it is quite often, that the same 
sensor takes longer to read soon again.

And it can be any sensor, in the beginning, in the end, anywhere.
Then it can be weeks until this sensor makes a problem again.

Could this be cause by asynchronous and parallel requests to owserver?


Sorry, no idea: this question is for the OWFS gurus

did anybody expierience similar issues?
I did upgrade to 3.1 and it still is the same.
With the new version I have the debug functionality back, which was 
missing in 2.9p8, so I will have to send the debug of owserver to a file 
and put the result up here if this would help finding the problem...






Stefano, would it be possible to have a max timeout while issuing a 
read command? How will I know that sometimes it won't take even longer?




In pyownet.protocol there is a 2 second timeout on the socket 
operations, see


https://github.com/miccoli/pyownet/blob/master/src/pyownet/protocol.py#L117
https://github.com/miccoli/pyownet/blob/master/src/pyownet/protocol.py#L310

this means that if the owserver crashes or the network connection is 
somehow interrupted the pyownet operation will fail with a 
pyownet.protocol.ConnError exception.
yes, that works fine. I did some tests before changing over to your 
library and found it very behaved in all sorts of special situations...




In your case, since the read takes longer than 2s (4 seconds and 
more), owserver is sending it’s keep-alive packets back to pyownet, so 
no socket timeout. This situation is handled below line

https://github.com/miccoli/pyownet/blob/master/src/pyownet/protocol.py#L347
As you can see, as long as owserver keeps sending it’s -1 payload 
frames, pyownet will block indefinitely. However this should not 
happen in practice, because owserver aborts the connection after 30 
seconds or so.


Here it could be possible to start a timer, and abort the connection 
pyownet side after a user configurable amount of time; or simply count 
the number of frames received and abort after a user configurable 
amount of frames.


I don’t know which is the correct strategy: fortunately these long 
reads are very rare events: maybe the present code is OK. pyownet 
simply trusts owserver and patiently keeps waiting as long as owserver 
tells him to do so.
I would say, it would be nice to have, but as you said not urgently 
necessary.
So far I have seen only one sensor with a delayed read-out at a time, so 
it is acceptable.
For some sensors however it is important that they will be read every 30 
seconds, and with a timeout I could ensure to match that interval, and 
to give up reading when it takes too long and just use the extrapolated 
value from the last couple of readings instead.



Cheers

Martin

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Getting simultaneous to work (and other)

[Martin Patzak (GMX)]

On 01/08/2016 02:26 AM, Jan Kandziora wrote:
> Am 08.01.2016 um 01:07 schrieb Stefano Miccoli:
>> I agree: since owserver is multi-threaded by design there is nothing
>> wrong with multiple client tasks/threads accessing it concurrently.
>> One should just avoid clogging the server wit an excessive number of
>> requests.
>>
> All is fine as long as you are not insisting on the order in which
> requests are served. That is because the owserver protocol is based on
> TCP, so the order of requests is only honoured per-socket. As soon there
> are multiple sockets, messages stuck in them are handled as the
> scheduler decides. And this isn't round-robin and not sorted by arriving
> time either. It's a complicated scheme based on throughput.
Thanks for giving more insight to the inner workings of owserver...
>
> So if you require to control the order of commands -as with
> synchronizing /simultaneous/temperature triggers to readouts of the
> chips-, you have to stuff them into the same socket on owserver side.
Ok, that is understood.


Cheers

Martin


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Getting simultaneous to work (and other)

[Martin Patzak (GMX)]

On 01/07/2016 10:11 AM, Stefano Miccoli wrote:

On 06 Jan 2016, at 12:32, Henrik Östman  wrote:


And that's it. Just one thread to not confuse the bus and the good thing is that I no 
longer experience the "found 0 devices"-problem I had before when running 
multiple thread and doing a bus scan. Probably the threads was lock too long in Owserver 
so somekind of timeout was reached as you suggested.

While writing my python owserver client I encountered a similar problem, see 
https://github.com/miccoli/pyownet/pull/1

A not well documented feature of owserver is that it sends keep-alive packets 
to the client when an operation takes longer than a given amount of time. The 
client has to discard these packets and keep waiting. (This is a common 
pitfall, see http://sourceforge.net/p/owfs/mailman/message/34211145/ )


I am using the pyownet library to communicate to a local owserver.
I have 25 temp-sensors and 2 io 2408 modules on one powered bus with an 
usb-link as master.


I do use simultaneous to read all 25 sensors every 30 seconds as well 
(see below)

From a seperate task I am reading the state of the 1-wire IOs every second.
Another task lets a LED flash, that is connected to one of the Outputs, 
also every second (as an indicator of the state of the system)


The system runs 24/7 and is mainly busy running the heating system in 
our house.
Additionally I do have separate tasks for running the furnace and the 
floor and radiator-circuits.


Using parallel tasks to communicate to owserver, was just a more natural 
and also an easier approach for me, and have owserver serialize the 
1-wire communication. (is that not advised???)


Henrik, what was your reason to rewrite your software to communicate 
only from one task to owserver?


In general everything is fine, but *sometimes*, reading a 
temperature-sensor takes a little longer (normally it takes between 0.1 
and 0.2s per sensor, so 25 sensors take about 1.5 to 2.5s). When it 
takes longer, reading a sensor can take as long as 4(!) seconds, however 
it usually is 0.5 to 0.7 seconds. I do log, when it takes longer, and 
this is how I know.


Here is one of the more interesting excerpts from my logs:

/1452153935.340 09:05:35 HC-Temp-Log reading the temperature of 
28.AF531F06 took longer: 2.36seconds //
//1452153936.315 09:05:36 HC-Temp-Log Reading Temps took a little longer 
: 4.22 seconds //
//1452153965.491 09:06:05 HC-Temp-Log reading the temperature of 
28.AF531F06 took longer: 2.42seconds //
//1452153966.702 09:06:06 HC-Temp-Log Reading Temps took a little longer 
: 4.64 seconds//
//1452154055.099 09:07:35 HC-Temp-Log reading the temperature of 
28.AF531F06 took longer: 2.35 seconds//
//1452154055.985 09:07:35 HC-Temp-Log Reading Temps took a little longer 
: 3.86 seconds//
//1452154085.459 09:08:05 HC-Temp-Log reading the temperature of 
28.AF531F06 took longer: 2.41 seconds//
//1452154086.616 09:08:06 HC-Temp-Log Reading Temps took a little longer 
: 4.49 seconds//
//1452154115.309 09:08:35 HC-Temp-Log reading the temperature of 
28.AF531F06 took longer: 2.39 seconds//
//1452154116.242 09:08:36 HC-Temp-Log Reading Temps took a little longer 
: 4.12 seconds//
//1452154145.268 09:09:05 HC-Temp-Log reading the temperature of 
28.AF531F06 took longer: 2.41 seconds//
//1452154146.162 09:09:06 HC-Temp-Log Reading Temps took a little longer 
: 4.10 seconds//
//1452154175.325 09:09:35 HC-Temp-Log reading the temperature of 
28.AF531F06 took longer: 2.32 seconds//
//1452154176.295 09:09:36 HC-Temp-Log Reading Temps took a little longer 
: 4.19 seconds//

/
In this case it is the same sensor that takes longer to read in 
consequent reads for 7 times.
When a read takes longer, than it is quite often, that the same sensor 
takes longer to read soon again.

And it can be any sensor, in the beginning, in the end, anywhere.
Then it can be weeks until this sensor makes a problem again.

Could this be cause by asynchronous and parallel requests to owserver?

Stefano, would it be possible to have a max timeout while issuing a read 
command? How will I know that sometimes it won't take even longer?


*Occasionally* reading a temp-sensor fails completely with the error:
/
//1452093633.364 16:20:33 HC-Temp-Log error from owt.RD_Temp: -1, [Errno 
1] Startup - command line parameters invalid: '28.CF791502/temperature'

1452093633.610 16:20:33 HC-Monitor 28.CF791502 is not present
1452093636.839 16:20:36 HC-Monitor 28.CF791502 is now present, 
setting OK to True

/

In that case, it looks like the sensor is not connected to the bus!?!
The task that reads the temps sets a flag, that a particular sensor has 
a problem, and continues reading the other sensors.
Meanwhile a seperate monitoring task picks up the flag and checks for 
the sensor at a certain interval. As you can see the sensor is actually 
not present, only to be present at the next check-interval 3 seconds 
later. Where was the sensor in the 

Re: [Owfs-developers] Raspberry pi 2, owserver

[Martin Patzak (GMX)]

debian / raspian / bananian 'upgrading' to owfs 3.1p0 on jessie:

since owfs 3.1p0 is not available on jessie, one can manually install 
the new packages by respecting the dependancies:


(take the following instructions at your own risk! And kids: don't do 
this at home or on a production system)


download the packages you want to upgrade for your architecture from the 
archives :


additionally the packages libow 
 and owfs-common 
 are needed mandatory



cd into the folder the packages are residing


install first owfs-common:

$ sudo dpkg --install owfs-common_3.1p0-1_all.deb


followed by lib-ow:

$ sudo dpkg --install libow-3.1-0_3.1p0-1_.deb


then you can install the packages you want to upgrade in the same fashion.

This was testet on bananian jessie only...

Cheers,

Martin


On 12/27/2015 10:22 AM, Jan Kandziora wrote:

Am 27.12.2015 um 08:22 schrieb Haas Martin:

Hi i am not able run owserver White startup parametr --w1,  my raspberry pi
2 is confgigured to use gpio 4 for onewire, ow server can't read from
kernel driver.


With distribution do you use? Raspbian?

There are various reasons why this may fail. Debugging requires you to
update to the latest version of the owfs package for Raspberry Pi, which
is 3.1p0, as Vincent had this disabled in his packages previously.

After updating, run owserver with the --debug switch and send the log.


In addition, as we recently found there has been a kernel update in
various Raspberry distributions which breaks the w1 support inside owfs.
So if you use a recent kernel, you have to compile the owfs package for
Raspberry yourself. Please use the latest version from git archive.

$ git clone git://git.code.sf.net/p/owfs/code owfs-code

Kind regards

Jan





--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owserver does not print information according to --error_level setting

[Martin Patzak (GMX)]

On 11/09/2015 02:29 PM, Jan Kandziora wrote:
> Am 09.11.2015 um 09:26 schrieb Martin Patzak (GMX):
>> Depending on your built and packaging the --debug option may merely
>> print a DEBUG statement, but not actually do any debugging.
>>
> Really, I don't know why the debian package maintainer disabled debug
> support at all. Maybe there's another package ...-debug which has it
> enabled?
I would not know either and the only package I can find related to debug 
is owfs-dbg, which is not the one:

description of package owfs-dbg:

This package contains gdb debugging symbols for OWFS packages.
You need this if you see crashes in programs using 1-wire.


I was searching in the changelogs for anything related to debug:

mnm@razmaban:~$ cat /usr/share/doc/ow*/changelog* |grep -B3 debug
2010-06-06 15:42  alfille

 * module/owlib/src/c/ow_write.c: Added some debug messages to write
--

owfs (2.8p13+dfsg1-4) unstable; urgency=low

   * disable malloc debug at configure time
--
  -- Vincent Danjean <vdanj...@debian.org>  Sun, 21 Nov 2010 23:04:19 +0100

... repeated by more of the above


The package maintainer is Vincent <vdanj...@debian.org>, would you 
please ask him what is going on?
Does nobody else have any problems with --debug and owserver?

My version is the official jessie package packaged for arm platform, 
which is 2.9p8

Btw. just to be sure I installed now owserver on my PC, an amd64 
platform, and debug is still empty, besides the print statement in the 
beginning.

Moreover hooking up an owserver on the PC to the bananian also does not 
give me the correct CRC16_errors value.
Additionally I found out, that e.g. changing the timeout for volatile to 
something other than 15 on the owserver on the PC does not get 
propagated to the the "master" owserver. But that could be a convention, 
I guess.

Thanks,

Martin


--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a 
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owserver does not print information according to --error_level setting

[Martin Patzak (GMX)]

cool! I like it ;o)

On 11/09/2015 02:53 PM, Jan Kandziora wrote:

Am 09.11.2015 um 09:26 schrieb Martin Patzak (GMX):

To recap:
the debian package for owfs and owserver does not honor --debug option,
but merely prints a DEBUG statement in the beginning
owfs does print error-level information of level 3 only, if
--error-level is set to 3 or higher. If --error-level is set to 2 or
lower it prints nothing
owserver does not print error-level information whatsoever.


https://sourceforge.net/p/owfs/code/ci/44de1521b6b4ec54095e719e95483db617aed648/

Kind regards

Jan

--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a 
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 'strange' value reading /sensed.BYTE of a DS2408 (Martin Patzak (GMX))

[Martin Patzak (GMX)]

Loren will be excited to read this. Who is the funny bunny now?

On 11/09/2015 03:46 PM, Stefano Miccoli wrote:

Curiously I ran in a similar situation as the BBB:

$ python -m test.timing //10.48.74.119/
pyownet: ver. 0.8.2
proxy_obj: ownet server at ('10.48.74.119', 4304)
server info: pid 2443, ver. unknown

timeit:
 statement: proxy_obj.dir("/")
 number: 20
 repetitions: 5

** non persistent : 39.96 ms, 39.99 ms, 40.00 ms, 40.01 ms, 40.21 ms,
** persistent : 39.98 ms, 40.00 ms, 40.00 ms, 40.00 ms, 40.00 ms,


The reason for this slow “dir” seems linked in my case to a ‘bug' in 
owserver (debian version 2.8p15-1).

In fact the original configuration (owfs.conf) is

server: link = /dev/ttyS0
server: server = owserver.example.com <http://owserver.example.com>:4304

When I substitute the fqdn with the IP number I get

$ python -m test.timing //10.48.74.119/
pyownet: ver. 0.8.2
proxy_obj: ownet server at ('10.48.74.119', 4304)
server info: pid 28029, ver. unknown

timeit:
 statement: proxy_obj.dir("/")
 number: 20
 repetitions: 5

** non persistent :  2.14 ms,  2.15 ms,  2.15 ms,  2.16 ms,  2.23 ms,
** persistent :  1.90 ms,  1.92 ms,  1.94 ms,  1.95 ms,  1.96 ms,

I would think that owserver v2.8p15 is not caching the result of the 
DNS query (getaddrinfo()), which is quite slow.


(BTW one of the reasons for which my pyownet can be quite fast if 
compared with ownet is that getaddrinfo() is called only at proxy 
object creation and then cached in the proxy object. In ownet , on the 
contrary, if you specify a domain name instead of an IP number, the 
DNS is queried at each owserver query.)


S.M.


On 07 Nov 2015, at 22:27, Loren Amelang <lo...@pacific.net 
<mailto:lo...@pacific.net>> wrote:


On Sat, 07 Nov 2015 09:21:43 +0100
"Martin Patzak (GMX)" martin.pat...@gmx.de 
<mailto:martin.pat...@gmx.de> wrote:



why don't you try and run Stefanos timing program directly on your
Beagle and see what timing you get there


Posted that earlier:

ubuntu@arm:~/Lpkg$ python3 StefanoTimingTest.py3
** non persistent : 37.55 ms, 37.78 ms, 39.26 ms, 40.15 ms, 41.11 ms,
** persistent : 36.22 ms, 36.41 ms, 36.62 ms, 37.10 ms, 38.26 ms,

C:\Users\Loren\Documents\Projects\Computing\BeagleBone Black\BBB 
Projects\1-Wire\OWFS Python logging>python ** non persistent : 41.69 
ms, 45.79 ms, 45.99 ms, 48.34 ms, 49.41 ms,

** persistent : 42.26 ms, 44.03 ms, 45.68 ms, 45.69 ms, 46.03 ms,

I suspect the 1.1 mS ping overhead of the Windows Wi-Fi link more 
than wiped out the faster Python execution by the more competent 
external machine.


Well, maybe not...  Here's Windows wired to the network:

C:\Users\Loren\Documents\Projects\Computing\BeagleBone Black\BBB 
Projects\1-Wire\OWFS Python logging>python ** non persistent : 42.48 
ms, 43.65 ms, 44.34 ms, 44.82 ms, 47.53 ms,

** persistent : 38.35 ms, 39.17 ms, 40.23 ms, 41.67 ms, 42.80 ms,

A bit better than Wi-Fi, but still slower than running everything on 
the BBB! I'd have expected results more like yours, with the external 
machine faster than testing from the little board:


mnm @ razmaban:~/python$ python pyownet_timing.py
** non persistent :  3.18 ms,  3.24 ms,  3.24 ms,  3.25 ms,  3.47 ms,
** persistent :  2.37 ms,  2.39 ms,  2.40 ms,  2.42 ms,  2.58 ms,

mnm @ vincent:~/M/_Linux/python/_mnms_tests$ python pyownet_timing.py 
//razmaban:4304

** non persistent :  2.40 ms,  2.40 ms,  2.43 ms,  2.44 ms,  2.49 ms,
** persistent :  1.82 ms,  1.82 ms,  1.86 ms,  2.05 ms,  2.12 ms,


One curiosity seems to persist in all configurations - each later 
test in the same sequence takes a bit longer! Guess I can't 
understand everything...


Loren

| Loren Amelang | lo...@pacific.net <mailto:lo...@pacific.net> |




--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net 
<mailto:Owfs-developers@lists.sourceforge.net>

https://lists.sourceforge.net/lists/listinfo/owfs-developers




--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a 
more interactive manner. Teradata is also now p

Re: [Owfs-developers] owserver does not print information according to --error_level setting

[Martin Patzak (GMX)]

Loren,

thanks for your efforts, but in a previous version of owfs the error 
logging worked fine for me too.

It is like Jan said, it is build without or too little debug information.

Martin


--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a 
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 'strange' value reading /sensed.BYTE of a DS2408 (Martin Patzak (GMX))

[Martin Patzak (GMX)]

On 11/07/2015 10:27 PM, Loren Amelang wrote:
> On Sat, 07 Nov 2015 09:21:43 +0100
> "Martin Patzak (GMX)" martin.pat...@gmx.de wrote:
>
>> why don't you try and run Stefanos timing program directly on your
>> Beagle and see what timing you get there
> Posted that earlier:
>   
ok, sorry I did not realize you already did a local test...
>
>   
> One curiosity seems to persist in all configurations - each later test in the 
> same sequence takes a bit longer! Guess I can't understand everything...
your beagle seems to be a funny bunny...



--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a 
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owserver does not print information according to --error_level setting

[Martin Patzak (GMX)]

On 11/07/2015 04:56 PM, Jan Kandziora wrote:
>
> --debug is the same as "--foreground --error_level=9"
>
> See module/owlib/src/c/ow_opt.c:733ff
ok, I see
>
> That's the output when debug support wasn't selected at compile time.
ok, that added to my confusion a bit
>
>
>>> You are using a build without debugging support. Please take the owfs
>>> sources and configure/compile for yourself.
I will have to bite the bullet eventually and setup a build enviroment 
on my PC then
>> And why does it print DEBUG MODE at all?
>>
> That's a simple printf() at module/owlib/src/c/ow_opt.c:735, which isn't
> connected to any compile-time option.
thats another piece of the puzzle then
>
> Kind regards
>
>   Jan
Thanks Jan, for your efforts to clears this one up.

To recap:
the debian package for owfs and owserver does not honor --debug option, 
but merely prints a DEBUG statement in the beginning
owfs does print error-level information of level 3 only, if 
--error-level is set to 3 or higher. If --error-level is set to 2 or 
lower it prints nothing
owserver does not print error-level information whatsoever.

It would be helpful, if this would be reflected in the man-page for 
owserver and owfs under JOB CONTROL OPTIONS

Something like:

--debug

Depending on your built and packaging the --debug option may merely 
print a DEBUG statement, but not actually do any debugging.

--error_level=0..9

Depending on your built and packaging the --error-level option might not 
be honored.

If you need more error printing, you may have to build from source. 
Thank You


Cheers

Martin





--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a 
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Ocean Temperature

[Martin Patzak (GMX)]

Peter,

we used to make our splices ourselves, to adapt them to our special 
needs and to avoid any connectors whatsoever.


In aggressive enviroment like seawater we would use stainless tubing to 
encase the splicing as well as to house the sensor itself.
Then we did fill the tube with 2 component epoxy and for faster and 
bubble-free curing we put this into an oven to cure for an hour or so at 
100 Celsius - but that depents on the epoxy you use


Cheers,

Martin


On 11/07/2015 02:37 AM, Peter Hollenbeck wrote:

I'll do as you suggest on the splice.
Thank you for your input.
Peter

On Fri, Nov 6, 2015 at 1:21 PM, Colin Reese > wrote:


You're going to need a waterproof butt splice of some sort. I
would probably solder, heat shrink, and epoxy. Cable should be
fine. Might as well double up conductors, could even use four
conductors for ground if you wanted.

C

On Fri, Nov 6, 2015 at 1:11 PM, Peter Hollenbeck
> wrote:

Ocean temperature at depth of about 5 feet.

On Fri, Nov 6, 2015 at 1:08 PM, Jan Kandziora > wrote:

Am 06.11.2015 um 21:24 schrieb Peter Hollenbeck:
> I ordered one of these:
> Waterproof DS18B20 Digital temperature sensor
>
> Where I want to measure is 170 feet
>
What do you want to measure? 170 feet seawater depth?

Kind regards

Jan


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/owfs-developers




--

___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/owfs-developers




--

___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/owfs-developers




--


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 'strange' value reading /sensed.BYTE of a DS2408 (Stefano Miccoli)

[Martin Patzak (GMX)]

the error pointer is under the letter t of the statement print:

mnm@vincent:~/M/_Linux/python/_mnms_tests$ python 
pyownet_run_out_of_sockets.py

  File "pyownet_run_out_of_sockets.py", line 13
None if i % freq else print('Iteration {}'.format(i))
  ^
SyntaxError: invalid syntax


On 11/06/2015 01:10 PM, Martin Patzak (GMX) wrote:

Stefano,

I wanted to try your program, but I get an error message:

mnm@vincent:~/M/_Linux/python/_mnms_tests$ python 
pyownet_run_out_of_sockets.py

  File "pyownet_run_out_of_sockets.py", line 13
None if i % freq else print('Iteration {}'.format(i))
  ^
SyntaxError: invalid syntax

since I am not very familiar with python I do not find the error on 
the spot... maybe you can help me out



btw. the line

p = protocol.proxy(‘myowserver', persistent=False)

there is a typo: the first ' after ( is not a ' but a ‘ - it's hard to 
see here, but with syntax highlighting it is easy to spot ;o)


Martin


On 11/06/2015 11:20 AM, Stefano Miccoli wrote:
A proxy object with 'persistent=False'will bind and destroy a socket 
for each call to the owserver. (If you call 'netstat -t’ after the 
timing test you will see hundreds of lines like
tcp0  0 localhost:45494 localhost:4304
  TIME_WAIT

which is the debris that remains after you tear down a socket…)

On the contrary with  ‘persistent=True'a single socket is bound at 
the beginning of the transaction and reused for every subsequent 
owserver call. So 'persistent=False’ has a very small overhead (about 
1ms) for each call.


Somehow your figures are consistent with this interpretation: 
non-persistent overhead is a constant small delta with respect to 
persistent connection. Since your owserver is apparently much slower 
than the one which I run my tests, you have a smaller relative overhead.


Usually I would not care about the persistent/non persistent thing, 
unless you are running out of available sockets.


This program

import itertools
from pyownet import protocol

p = protocol.proxy(‘myowserver', persistent=False)
freq = 1 << 12

for i in itertools.count():
try:
c = p.dir()
except protocol.Error as exc:
print('Iteration {0} raised exception: {1}'.format(i, exc))
break
None if i % freq else print('Iteration {}'.format(i))


prints

Iteration 0
Iteration 4096
Iteration 8192
Iteration 12288
Iteration 16384
Iteration 16977 raised exception: [Errno 49] Can't assign requested 
address


so it is possible to run out of sockets, although this is a rather 
edgy situation, that I’ve never analysed in detail.


S.

On 06 Nov 2015, at 02:26, Loren Amelang <lo...@pacific.net 
<mailto:lo...@pacific.net>> wrote:


On Thu, 05 Nov 2015 13:02:13 +0100,
Stefano Miccoli mo...@icloud.com <mailto:mo...@icloud.com> wrote:
...

Just a few numbers, collected with
https://github.com/miccoli/pyownet/blob/master/test/timing.py
<https://github.com/miccoli/pyownet/blob/master/test/timing.py> 
querying a

non localhost production owserver



pyownet: ver. 0.8.2
proxy_obj: ownet server at ('10.48.74.112', 4304)
server info: pid 2662, ver. unknown

timeit:
statement: proxy_obj.dir("/")
number: 20
repetitions: 5

** non persistent :  1.29 ms,  1.30 ms,  1.30 ms,  1.33 ms,  1.36 ms,
** persistent :  0.77 ms,  0.77 ms,  0.79 ms,  0.80 ms,  0.97 ms,


The figure reported here are time for a single call to the given 
method,
computed as the average of 20 consecutive calls. (Please note that 
I read
the cached temperature value? uncached is of course much slower, 
but this

is due to 1-wire)



I was surprised by the timing numbers you posted. So I tried your 
test script with my BBB installation...


Running on the BBB with the owserver:
---
ubuntu@arm:~/Lpkg$ python3 StefanoTimingTest.py3
pyownet: ver. 0.8.2 
(/usr/local/lib/python3.4/dist-packages/pyownet/__init__.py)

proxy_obj: ownet server at ('127.0.0.1', 4304)
server info: pid 1243, ver. unknown

timeit:
statement: proxy_obj.dir("/")
number: 20
repetitions: 5

** non persistent : 37.55 ms, 37.78 ms, 39.26 ms, 40.15 ms, 41.11 ms,
** persistent : 36.22 ms, 36.41 ms, 36.62 ms, 37.10 ms, 38.26 ms,
---


Running Python on an external Windows machine, one Wi-Fi hop from 
the BBB:

---
C:\Users\Loren\Documents\Projects\Computing\BeagleBone Black\BBB 
Projects\1-Wire\OWFS Python logging>python StefanoTimingTest.py3 
owserver://10.1.1.4:4304
pyownet: ver. 0.8.2 
(C:\Apps\Python33\lib\site-packages\pyownet\__init__.py)

proxy_obj: ownet server at ('10.1.1.4', 4304)
server info: pid 22210, ver. unknown

timeit:
statement: proxy_obj.dir("/")
number: 20
repetitions: 5

** non persistent : 41.69 ms, 45.79 ms, 45.99 ms, 48.34 ms, 49.41 ms,
** persistent : 42.26 ms, 44.03 ms, 45.68 ms, 45.69 ms, 46.03 ms,
---


Between those two tests was a long learning session. For those who 
don't know...

[Owfs-developers] switching from owfs to owserver and using owfs through owserver issues

[Martin Patzak (GMX)]

Hello All,

I am going to switch over to owserver instead of using owfs.

In a transition phase I wanted to use owfs through owserver, so existing 
software can continue to run using the fuse directory, while in 
background owserver is running already.


After starting owserver, I started owfs with

owfs -s 4304 -m /mnt/1wire --allow_other

which runs fine for the devices, *but not for statistics or errors* and 
the like


For example CRC16_errors do *not* get handled through. All errors 
staying at zero on the owfs side, while they are changing on the 
owserver of course.


Neither is, to name a seconde one, settings/timeout/volatile. If I 
change the value from default 15 through a client in owserver, it does 
not get updated when I try to read this file through owfs.



Is that a known and normal behaviour?


Martin

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 'strange' value reading /sensed.BYTE of a DS2408 (Stefano Miccoli)

[Martin Patzak (GMX)]

On 11/06/2015 02:26 AM, Loren Amelang wrote:

On Thu, 05 Nov 2015 13:02:13 +0100,
Stefano Miccoli mo...@icloud.com wrote:
...

pyownet: ver. 0.8.2
proxy_obj: ownet server at ('10.48.74.112', 4304)
server info: pid 2662, ver. unknown

timeit:
statement: proxy_obj.dir("/")
number: 20
repetitions: 5

** non persistent :  1.29 ms,  1.30 ms,  1.30 ms,  1.33 ms,  1.36 ms,
** persistent :  0.77 ms,  0.77 ms,  0.79 ms,  0.80 ms,  0.97 ms,
The figure reported here are time for a single call to the given method,
computed as the average of 20 consecutive calls. (Please note that I read
the cached temperature value? uncached is of course much slower, but this
is due to 1-wire)
  
  
I was surprised by the timing numbers you posted. So I tried your test script with my BBB installation...


Running on the BBB with the owserver:
---
ubuntu@arm:~/Lpkg$ python3 StefanoTimingTest.py3
pyownet: ver. 0.8.2 (/usr/local/lib/python3.4/dist-packages/pyownet/__init__.py)
proxy_obj: ownet server at ('127.0.0.1', 4304)
server info: pid 1243, ver. unknown

timeit:
statement: proxy_obj.dir("/")
number: 20
repetitions: 5

** non persistent : 37.55 ms, 37.78 ms, 39.26 ms, 40.15 ms, 41.11 ms,
** persistent : 36.22 ms, 36.41 ms, 36.62 ms, 37.10 ms, 38.26 ms,
---


Running Python on an external Windows machine, one Wi-Fi hop from the BBB:
---
C:\Users\Loren\Documents\Projects\Computing\BeagleBone Black\BBB 
Projects\1-Wire\OWFS Python logging>python StefanoTimingTest.py3 
owserver://10.1.1.4:4304
pyownet: ver. 0.8.2 (C:\Apps\Python33\lib\site-packages\pyownet\__init__.py)
proxy_obj: ownet server at ('10.1.1.4', 4304)
server info: pid 22210, ver. unknown

timeit:
statement: proxy_obj.dir("/")
number: 20
repetitions: 5

** non persistent : 41.69 ms, 45.79 ms, 45.99 ms, 48.34 ms, 49.41 ms,
** persistent : 42.26 ms, 44.03 ms, 45.68 ms, 45.69 ms, 46.03 ms,
---



I cannot confirm Lorens numbers, but end up in the ballpark given by 
Stefano:


mnm@vincent:~/M/_Linux/python/_mnms_tests$ python pyownet_timing.py 
//razmaban:4304
pyownet: ver. 0.8.2 
(/usr/local/lib/python2.7/dist-packages/pyownet/__init__.pyc)

proxy_obj: ownet server at ('10.67.90.173', 4304)
server info: pid 21863, ver. 2.9p8

timeit:
 statement: proxy_obj.dir("/")
 number: 20
 repetitions: 5

** non persistent :  2.40 ms,  2.40 ms,  2.43 ms,  2.44 ms,  2.49 ms,
** persistent :  1.82 ms,  1.82 ms,  1.86 ms,  2.05 ms,  2.12 ms,

The test was run on a remote (local LAN) debian machine connecting to an 
owserver running on a bananapi running debian jessie with prebuilt owfs 
debian package version 2.9p8.
The tested 1wire net consists out of LinkUSB 
 as master, 2 DS2408 io-modules 
and 25 DS28B20 temperature sensors.


Cheers

Martin


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 'strange' value reading /sensed.BYTE of a DS2408 (Stefano Miccoli)

[Martin Patzak (GMX)]

Stefano,

I wanted to try your program, but I get an error message:

mnm@vincent:~/M/_Linux/python/_mnms_tests$ python 
pyownet_run_out_of_sockets.py

  File "pyownet_run_out_of_sockets.py", line 13
None if i % freq else print('Iteration {}'.format(i))
  ^
SyntaxError: invalid syntax

since I am not very familiar with python I do not find the error on the 
spot... maybe you can help me out



btw. the line

p = protocol.proxy(‘myowserver', persistent=False)

there is a typo: the first ' after ( is not a ' but a ‘ - it's hard to 
see here, but with syntax highlighting it is easy to spot ;o)


Martin


On 11/06/2015 11:20 AM, Stefano Miccoli wrote:
A proxy object with 'persistent=False'will bind and destroy a socket 
for each call to the owserver. (If you call 'netstat -t’ after the 
timing test you will see hundreds of lines like
tcp0  0 localhost:45494 localhost:4304
  TIME_WAIT

which is the debris that remains after you tear down a socket…)

On the contrary with  ‘persistent=True'a single socket is bound at the 
beginning of the transaction and reused for every subsequent owserver 
call. So 'persistent=False’ has a very small overhead (about 1ms) for 
each call.


Somehow your figures are consistent with this interpretation: 
non-persistent overhead is a constant small delta with respect to 
persistent connection. Since your owserver is apparently much slower 
than the one which I run my tests, you have a smaller relative overhead.


Usually I would not care about the persistent/non persistent thing, 
unless you are running out of available sockets.


This program

import itertools
from pyownet import protocol

p = protocol.proxy(‘myowserver', persistent=False)
freq = 1 << 12

for i in itertools.count():
try:
c = p.dir()
except protocol.Error as exc:
print('Iteration {0} raised exception: {1}'.format(i, exc))
break
None if i % freq else print('Iteration {}'.format(i))


prints

Iteration 0
Iteration 4096
Iteration 8192
Iteration 12288
Iteration 16384
Iteration 16977 raised exception: [Errno 49] Can't assign requested 
address


so it is possible to run out of sockets, although this is a rather 
edgy situation, that I’ve never analysed in detail.


S.

On 06 Nov 2015, at 02:26, Loren Amelang > wrote:


On Thu, 05 Nov 2015 13:02:13 +0100,
Stefano Miccoli mo...@icloud.com  wrote:
...

Just a few numbers, collected with
https://github.com/miccoli/pyownet/blob/master/test/timing.py
 
querying a

non localhost production owserver



pyownet: ver. 0.8.2
proxy_obj: ownet server at ('10.48.74.112', 4304)
server info: pid 2662, ver. unknown

timeit:
statement: proxy_obj.dir("/")
number: 20
repetitions: 5

** non persistent :  1.29 ms,  1.30 ms,  1.30 ms,  1.33 ms,  1.36 ms,
** persistent :  0.77 ms,  0.77 ms,  0.79 ms,  0.80 ms,  0.97 ms,



The figure reported here are time for a single call to the given method,
computed as the average of 20 consecutive calls. (Please note that I 
read
the cached temperature value? uncached is of course much slower, but 
this

is due to 1-wire)



I was surprised by the timing numbers you posted. So I tried your 
test script with my BBB installation...


Running on the BBB with the owserver:
---
ubuntu@arm:~/Lpkg$ python3 StefanoTimingTest.py3
pyownet: ver. 0.8.2 
(/usr/local/lib/python3.4/dist-packages/pyownet/__init__.py)

proxy_obj: ownet server at ('127.0.0.1', 4304)
server info: pid 1243, ver. unknown

timeit:
statement: proxy_obj.dir("/")
number: 20
repetitions: 5

** non persistent : 37.55 ms, 37.78 ms, 39.26 ms, 40.15 ms, 41.11 ms,
** persistent : 36.22 ms, 36.41 ms, 36.62 ms, 37.10 ms, 38.26 ms,
---


Running Python on an external Windows machine, one Wi-Fi hop from the 
BBB:

---
C:\Users\Loren\Documents\Projects\Computing\BeagleBone Black\BBB 
Projects\1-Wire\OWFS Python logging>python StefanoTimingTest.py3 
owserver://10.1.1.4:4304
pyownet: ver. 0.8.2 
(C:\Apps\Python33\lib\site-packages\pyownet\__init__.py)

proxy_obj: ownet server at ('10.1.1.4', 4304)
server info: pid 22210, ver. unknown

timeit:
statement: proxy_obj.dir("/")
number: 20
repetitions: 5

** non persistent : 41.69 ms, 45.79 ms, 45.99 ms, 48.34 ms, 49.41 ms,
** persistent : 42.26 ms, 44.03 ms, 45.68 ms, 45.69 ms, 46.03 ms,
---


Between those two tests was a long learning session. For those who 
don't know...


In netstat, "0.0.0.0" addresses are accessible from outside machines, 
127.0.0.1 addresses are not!


The localhost setting is in (at least) two places in /etc/owfs.conf:
! server: server = 10.1.1.4:4304  # localhost:4304 LA151105 allow net 
access

And:
server: port = 4304  # localhost:4304  LA151105 allow net access

After making those changes, I found "restart" does not notice them! 
You have to use "force-reload":

ubuntu@arm:~/Lpkg$ sudo 

[Owfs-developers] a tiny Pythonic excursion

[Martin Patzak (GMX)]

Stefano,

ok now I get it:

in Python you can write the statement before the condition. Brilliant!!!

all fruits and vegetables 
<http://stackoverflow.com/questions/2802726/putting-a-simple-if-then-statement-on-one-line> 
or more coconuts <https://en.wikipedia.org/wiki/%3F:#Python>


Martin

P.S. one more (and last) apology to the owfs list


On 11/06/2015 02:33 PM, Martin Patzak (GMX) wrote:



On 11/06/2015 02:13 PM, Stefano Miccoli wrote:
For the ‘ it was cut and paste but my mail likes to ameliorate my 
mail and distinguish between opening and closing quotes,

Ok, I see


Please find the program snippet at 
https://gist.github.com/miccoli/3df5e84624b50cb070de


I run the program with python3, where ‘print’ is a function, so the 
conditional expression xifCelsey is correct (see 
https://docs.python.org/3/reference/expressions.html#conditional-expressions)


With python 2.7 ‘print’ is a statement, thus the syntax error. Under 
python 2.7 you can add, as the first statement


from __future__ import print_function

and everything should run smoothly.

S.

yes, that does the trick.


mnm@vincent:~/M/_Linux/python/_mnms_tests$ python 
pyownet_run_out_of_sockets.py

Iteration 0
Iteration 4096
Iteration 8192
Iteration 12288
Iteration 16384
Iteration 20480
Iteration 24576
Iteration 28672
Iteration 32468 raised exception: [Errno 99] Cannot assign requested 
address





PS: not very pythonic and cryptic, but I prefer the one-liner

print(mess_if_True) if C else print(mess_if_False)

rather than

if C:
print(mess_True)
else:
print(mess_False)


maybe this does not belong in the owfs mailing list, so I apologize 
and keep it short:


I do not know much about much about Python, but I read somewhere that 
good python-code is like pseudo-code

so in that regard your one-liner is good Python after all.

BUT: what does the None do in front of the if??? It is not readable at 
all to me.


None if i % freq else print('Iteration {}'.format(i))




On 06 Nov 2015, at 13:10, Martin Patzak (GMX) <martin.pat...@gmx.de 
<mailto:martin.pat...@gmx.de>> wrote:


Stefano,

I wanted to try your program, but I get an error message:

mnm@vincent:~/M/_Linux/python/_mnms_tests$ python 
pyownet_run_out_of_sockets.py

  File "pyownet_run_out_of_sockets.py", line 13
None if i % freq else print('Iteration {}'.format(i))
  ^
SyntaxError: invalid syntax

since I am not very familiar with python I do not find the error on 
the spot... maybe you can help me out



btw. the line

p = protocol.proxy(‘myowserver', persistent=False)

there is a typo: the first ' after ( is not a ' but a ‘ - it's hard 
to see here, but with syntax highlighting it is easy to spot ;o)


Martin


On 11/06/2015 11:20 AM, Stefano Miccoli wrote:
A proxy object with 'persistent=False'will bind and destroy a 
socket for each call to the owserver. (If you call 'netstat -t’ 
after the timing test you will see hundreds of lines like

tcp   0  0 localhost:45494   localhost:4304  TIME_WAIT
which is the debris that remains after you tear down a socket…)

On the contrary with  ‘persistent=True'a single socket is bound at 
the beginning of the transaction and reused for every subsequent 
owserver call. So 'persistent=False’ has a very small overhead 
(about 1ms) for each call.


Somehow your figures are consistent with this interpretation: 
non-persistent overhead is a constant small delta with respect to 
persistent connection. Since your owserver is apparently much 
slower than the one which I run my tests, you have a smaller 
relative overhead.


Usually I would not care about the persistent/non persistent thing, 
unless you are running out of available sockets.


This program

import itertools
from pyownet import protocol

p = protocol.proxy(‘myowserver', persistent=False)
freq = 1 << 12

for i in itertools.count():
try:
c = p.dir()
except protocol.Error as exc:
print('Iteration {0} raised exception: {1}'.format(i, exc))
break
None if i % freq else print('Iteration {}'.format(i))


prints

Iteration 0
Iteration 4096
Iteration 8192
Iteration 12288
Iteration 16384
Iteration 16977 raised exception: [Errno 49] Can't assign requested 
address


so it is possible to run out of sockets, although this is a rather 
edgy situation, that I’ve never analysed in detail.


S.

On 06 Nov 2015, at 02:26, Loren Amelang <lo...@pacific.net 
<mailto:lo...@pacific.net>> wrote:


On Thu, 05 Nov 2015 13:02:13 +0100,
Stefano Miccoli mo...@icloud.com <mailto:mo...@icloud.com> wrote:
...

Just a few numbers, collected with
https://github.com/miccoli/pyownet/blob/master/test/timing.py
<https://github.com/miccoli/pyownet/blob/master/test/timing.py> 
querying a

non localhost production owserver



pyownet: ver. 0.8.2
proxy_obj: ownet server at ('10.48.74.112', 4304)
server info: pid 2662, ver. unknown

timeit:
statement: proxy_obj.dir("/")
number: 20

Re: [Owfs-developers] 'strange' value reading /sensed.BYTE of a DS2408 (Stefano Miccoli)

[Martin Patzak (GMX)]

On 11/06/2015 01:01 PM, Martin Patzak (GMX) wrote:



On 11/06/2015 02:26 AM, Loren Amelang wrote:

On Thu, 05 Nov 2015 13:02:13 +0100,
Stefano miccolimo...@icloud.com  wrote:
...

pyownet: ver. 0.8.2
proxy_obj: ownet server at ('10.48.74.112', 4304)
server info: pid 2662, ver. unknown

timeit:
statement: proxy_obj.dir("/")
number: 20
repetitions: 5

** non persistent :  1.29 ms,  1.30 ms,  1.30 ms,  1.33 ms,  1.36 ms,
** persistent :  0.77 ms,  0.77 ms,  0.79 ms,  0.80 ms,  0.97 ms,
The figure reported here are time for a single call to the given method,
computed as the average of 20 consecutive calls. (Please note that I read
the cached temperature value? uncached is of course much slower, but this
is due to 1-wire)
  
  
I was surprised by the timing numbers you posted. So I tried your test script with my BBB installation...


Running on the BBB with the owserver:
---
ubuntu@arm:~/Lpkg$ python3 StefanoTimingTest.py3
pyownet: ver. 0.8.2 (/usr/local/lib/python3.4/dist-packages/pyownet/__init__.py)
proxy_obj: ownet server at ('127.0.0.1', 4304)
server info: pid 1243, ver. unknown

timeit:
statement: proxy_obj.dir("/")
number: 20
repetitions: 5

** non persistent : 37.55 ms, 37.78 ms, 39.26 ms, 40.15 ms, 41.11 ms,
** persistent : 36.22 ms, 36.41 ms, 36.62 ms, 37.10 ms, 38.26 ms,
---


Running Python on an external Windows machine, one Wi-Fi hop from the BBB:
---
C:\Users\Loren\Documents\Projects\Computing\BeagleBone Black\BBB 
Projects\1-Wire\OWFS Python logging>python StefanoTimingTest.py3 
owserver://10.1.1.4:4304
pyownet: ver. 0.8.2 (C:\Apps\Python33\lib\site-packages\pyownet\__init__.py)
proxy_obj: ownet server at ('10.1.1.4', 4304)
server info: pid 22210, ver. unknown

timeit:
statement: proxy_obj.dir("/")
number: 20
repetitions: 5

** non persistent : 41.69 ms, 45.79 ms, 45.99 ms, 48.34 ms, 49.41 ms,
** persistent : 42.26 ms, 44.03 ms, 45.68 ms, 45.69 ms, 46.03 ms,
---



I cannot confirm Lorens numbers, but end up in the ballpark given by 
Stefano:


mnm@vincent:~/M/_Linux/python/_mnms_tests$ python pyownet_timing.py 
//razmaban:4304
pyownet: ver. 0.8.2 
(/usr/local/lib/python2.7/dist-packages/pyownet/__init__.pyc)

proxy_obj: ownet server at ('10.67.90.173', 4304)
server info: pid 21863, ver. 2.9p8

timeit:
 statement: proxy_obj.dir("/")
 number: 20
 repetitions: 5

** non persistent :  2.40 ms,  2.40 ms,  2.43 ms,  2.44 ms,  2.49 ms,
** persistent :  1.82 ms,  1.82 ms,  1.86 ms,  2.05 ms,  2.12 ms,

The test was run on a remote (local LAN) debian machine connecting to 
an owserver running on a bananapi running debian jessie with prebuilt 
owfs debian package version 2.9p8.
The tested 1wire net consists out of LinkUSB 
<http://owfs.org/index.php?page=linkusb> as master, 2 DS2408 
io-modules and 25 DS28B20 temperature sensors.


Cheers

Martin


for the sake of science, the same test locally on the bananapi:

mnm@razmaban:~/python$ python pyownet_timing.py
pyownet: ver. 0.8.2 
(/usr/local/lib/python2.7/dist-packages/pyownet/__init__.pyc)

proxy_obj: ownet server at ('127.0.0.1', 4304)
server info: pid 21863, ver. 2.9p8

timeit:
 statement: proxy_obj.dir("/")
 number: 20
 repetitions: 5

** non persistent :  3.18 ms,  3.24 ms,  3.24 ms,  3.25 ms,  3.47 ms,
** persistent :  2.37 ms,  2.39 ms,  2.40 ms,  2.42 ms,  2.58 ms,


Loren, there could be something at odds with your setup.

Martin



--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 'strange' value reading /sensed.BYTE of a DS2408 (Stefano Miccoli)

[Martin Patzak (GMX)]

On 11/06/2015 02:13 PM, Stefano Miccoli wrote:
For the ‘ it was cut and paste but my mail likes to ameliorate my mail 
and distinguish between opening and closing quotes,

Ok, I see


Please find the program snippet at 
https://gist.github.com/miccoli/3df5e84624b50cb070de


I run the program with python3, where ‘print’ is a function, so the 
conditional expression xifCelsey is correct (see 
https://docs.python.org/3/reference/expressions.html#conditional-expressions)


With python 2.7 ‘print’ is a statement, thus the syntax error. Under 
python 2.7 you can add, as the first statement


from __future__ import print_function

and everything should run smoothly.

S.

yes, that does the trick.


mnm@vincent:~/M/_Linux/python/_mnms_tests$ python 
pyownet_run_out_of_sockets.py

Iteration 0
Iteration 4096
Iteration 8192
Iteration 12288
Iteration 16384
Iteration 20480
Iteration 24576
Iteration 28672
Iteration 32468 raised exception: [Errno 99] Cannot assign requested address




PS: not very pythonic and cryptic, but I prefer the one-liner

print(mess_if_True) if C else print(mess_if_False)

rather than

if C:
print(mess_True)
else:
print(mess_False)


maybe this does not belong in the owfs mailing list, so I apologize and 
keep it short:


I do not know much about much about Python, but I read somewhere that 
good python-code is like pseudo-code

so in that regard your one-liner is good Python after all.

BUT: what does the None do in front of the if??? It is not readable at 
all to me.


None if i % freq else print('Iteration {}'.format(i))




On 06 Nov 2015, at 13:10, Martin Patzak (GMX) <martin.pat...@gmx.de 
<mailto:martin.pat...@gmx.de>> wrote:


Stefano,

I wanted to try your program, but I get an error message:

mnm@vincent:~/M/_Linux/python/_mnms_tests$ python 
pyownet_run_out_of_sockets.py

  File "pyownet_run_out_of_sockets.py", line 13
None if i % freq else print('Iteration {}'.format(i))
  ^
SyntaxError: invalid syntax

since I am not very familiar with python I do not find the error on 
the spot... maybe you can help me out



btw. the line

p = protocol.proxy(‘myowserver', persistent=False)

there is a typo: the first ' after ( is not a ' but a ‘ - it's hard 
to see here, but with syntax highlighting it is easy to spot ;o)


Martin


On 11/06/2015 11:20 AM, Stefano Miccoli wrote:
A proxy object with 'persistent=False'will bind and destroy a socket 
for each call to the owserver. (If you call 'netstat -t’ after the 
timing test you will see hundreds of lines like

tcp   0  0 localhost:45494   localhost:4304  TIME_WAIT
which is the debris that remains after you tear down a socket…)

On the contrary with  ‘persistent=True'a single socket is bound at 
the beginning of the transaction and reused for every subsequent 
owserver call. So 'persistent=False’ has a very small overhead 
(about 1ms) for each call.


Somehow your figures are consistent with this interpretation: 
non-persistent overhead is a constant small delta with respect to 
persistent connection. Since your owserver is apparently much slower 
than the one which I run my tests, you have a smaller relative overhead.


Usually I would not care about the persistent/non persistent thing, 
unless you are running out of available sockets.


This program

import itertools
from pyownet import protocol

p = protocol.proxy(‘myowserver', persistent=False)
freq = 1 << 12

for i in itertools.count():
try:
c = p.dir()
except protocol.Error as exc:
print('Iteration {0} raised exception: {1}'.format(i, exc))
break
None if i % freq else print('Iteration {}'.format(i))


prints

Iteration 0
Iteration 4096
Iteration 8192
Iteration 12288
Iteration 16384
Iteration 16977 raised exception: [Errno 49] Can't assign requested 
address


so it is possible to run out of sockets, although this is a rather 
edgy situation, that I’ve never analysed in detail.


S.

On 06 Nov 2015, at 02:26, Loren Amelang <lo...@pacific.net 
<mailto:lo...@pacific.net>> wrote:


On Thu, 05 Nov 2015 13:02:13 +0100,
Stefano Miccoli mo...@icloud.com <mailto:mo...@icloud.com> wrote:
...

Just a few numbers, collected with
https://github.com/miccoli/pyownet/blob/master/test/timing.py
<https://github.com/miccoli/pyownet/blob/master/test/timing.py> 
querying a

non localhost production owserver



pyownet: ver. 0.8.2
proxy_obj: ownet server at ('10.48.74.112', 4304)
server info: pid 2662, ver. unknown

timeit:
statement: proxy_obj.dir("/")
number: 20
repetitions: 5

** non persistent :  1.29 ms,  1.30 ms,  1.30 ms,  1.33 ms,  1.36 ms,
** persistent :  0.77 ms,  0.77 ms,  0.79 ms,  0.80 ms,  0.97 ms,


The figure reported here are time for a single call to the given 
method,
computed as the average of 20 consecutive calls. (Please note that 
I read
the cached temperature value? uncached is of course much slower, 
but this

is due to 1-wire)



I w

Re: [Owfs-developers] 'strange' value reading /sensed.BYTE of a DS2408

[Martin Patzak (GMX)]

pyownet: ver. 0.8.2
proxy_obj: ownet server at ('10.48.74.112', 4304)
server info: pid 2662, ver. unknown

timeit:
 statement: proxy_obj.dir("/")
 number: 20
 repetitions: 5

** non persistent :  1.29 ms,  1.30 ms,  1.30 ms, 1.33 ms,  1.36 ms,
** persistent :  0.77 ms,  0.77 ms,  0.79 ms, 0.80 ms,  0.97 ms,


timeit:
 statement: proxy_obj.read("/26./temperature")
 number: 20
 repetitions: 5

** non persistent :  1.14 ms,  1.16 ms, 1.16 ms,  1.19 ms,  1.40 ms,
** persistent :  0.63 ms,  0.64 ms, 0.66 ms,  0.95 ms,  0.98 ms,


that performance looks very good!

Since I use the "simultaneous" function with all sensors powered, it 
would result to the same speed, once the temperatures are converted.
I am curious if there is a feedback from owserver, when conversion is 
done? I will have to investigate...


And for switching outputs the speed should be also magnitudes faster 
than I need it!


I use the 1wire system to drive our heating system, consisting out of a 
wood burning oven, which is heating water up to 95 degrees and being 
pumped into two 800l buffer-tanks.
From there we have two circuits with water-mixers connected to 1wire 
2408. One circuit is a couple of radiators and the other one is floor 
heating.


I am reading 25 temp-sensors every 30 seconds.
There is one task controlling pump and mixer for the radiators and 
another one for the floor heating.

Another task is switching an output every second as kind of an alive beacon

here is a screenshot 
 of the HMI 
which of course is work in progress ;o) It is based on SVG widgets 
converted into XHTML and java-script which is done with HMI-Builder 



It grew over the years. The latest addition is the second buffer-tank, 
which has a built-in stainless steel tubing, that is heating our 
drinking water. It also has connection to hook up solar thermal 
collectors and heat water in the summer month. But that is a future project.


For doing the necessary changes I just have to find a way to simulate 
the bus with owserver - I read some time ago that there is a possibility 
to do this.
I cannot test on our live system of course. Maybe I have to wait for the 
spring...


It was easy to do this with the fuse filesystem. I just copied the live 
1wire directory and use the copy. I have a flag, when I am running a 
simulated bus, and when writing the PIO.bit I write the sensed.BYTE and 
the sensed.BIT accordingly.


Stefano, thanks for the data and your advise,

Martin


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 'strange' value reading /sensed.BYTE of a DS2408

[Martin Patzak (GMX)]

On 11/04/2015 02:02 PM, Jan Kandziora wrote:
> Am 04.11.2015 um 12:32 schrieb Martin Patzak (GMX):
>> while further investigating the problem it looks like this:
>>
>> the value of sensed.BYTE toggles between *55* (00110111) and *183*
>> (10110111) for quite a while - so its only flipping one bit.
>>
>> When I increase the toggling speed, I can provoke my *553* error from
>> *sensed.BYTE* from once a day to several times a minute.
>>
>> It looks like reading the owfs-file *sensed.BYTE* in python 2.7 is not
>> an atomic function!?!
>>
>> Any thoughts?
>>
> That doesn't mean the function is non-atomic but it means a
> copy-to-buffer operation is broken, as it doesn't add the required \0 to
> the "55" string.
>
> Which python binding to you use? Do you
>
>   import ow
>
> or
>
>   import ownet
>
> ?
>
> Kind regards
>
>   Jan
>

Jan,

thanks for the quick reply.

I do not import ow or ownet, but read the file directly in the 
file-system mounted by owfs
I started out years ago with perl and then transferred part to python. I 
never got around using ow or ownet.

Can I read the \0 with a python .read() command?


The code looks like

- begin code -

def RD_IO_byte(st, path,  id, error):

 ## this function reads sensed.BYTE and returns the bits as list of 
INT starting with MSB
 ## if there is a problem it returns None and error[0] will be non-zero

 # path - full path to owfs
 # id - ID of 1-wire device
 # bits - a integer list of all 8 bits from 0 to 7, the whole byte


 id = os.path.join(path, id)
 error[0] = -99

 try:
 byte = open(id +'/sensed.BYTE',  'r') # open our fuse-file
 except:
 print text_de.name[st], 'Could not open ', id, '/sensed.BYTE 
for reading!'
 return None
 else:
 str_byte = byte.read() # read the integer value of 
BYTE as string
 byte.close()# close the fuse-file
 value = int(str_byte)# once in a while it crashes 
here, so we need to find out why
 if (value < 0) or (value > 255): print text_de.name[st], 'Got 
int-value ', value, ' from string ',str_byte,' reading ', id, 
'/sensed.BYTE '
 bits = int2bin(int(str_byte)) # make a bit-list out of the 
integer
 bits = invert_byte(bits) #
 error[0] = 0
 #print 'error in RD_IO_byte', error[0]
 return bits

- end code --


Martin

>
> --
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] 'strange' value reading /sensed.BYTE of a DS2408

[Martin Patzak (GMX)]

On 11/04/2015 04:16 PM, Jan Kandziora wrote:
> Am 04.11.2015 um 15:56 schrieb Stefano Miccoli:
>> I would not blame python, nor owfs, but fuse.
>>
> Not, it's not fuse.
>
> It's because read() is *not atomic*. As soon you read multi-byte values
> from files -such as files whioch contain an ASCII representation of
> numbers, as owfs has- you have to take care noone writes to that file at
> the same position at the same moment.
yes, that is precisely what is happening!

Jan,

thank you for your support and clarifying the situation

Martin


--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] 'strange' value reading /sensed.BYTE of a DS2408

[Martin Patzak (GMX)]

Hello All,

I am experiencing 'strange' readings from a DS2408.

Every once in a while (that is about once a day, with reading 
the*sensed.BYTE* folders once a second - so its rather rare) the value 
read from one of the *DS2408* is *553 *where it should be *between 0 and 
255.


*Is this some 'special' value indicating an error or something the like? 
Anybody else saw this phenomena before?


I throw this value away and*re-read* again and *everything is fine*!


I am running solely owfs 2.9p8 on a BananaPi running Debian 8 'jessie' 
(no owserver or owhttp is running).


There are 25 temperature sensors and 2 DS2408 on a powered bus with an 
USB-Link as bus-master.


While there is some perl-code writing to the PIO. of the DS2408, it 
is Python-code reading the sensed.BYTE of the 2408 to display the state 
in an HMI on a webpage.



Cheers

Martin

--
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] owserver don't detect the ds2482s-800 anymore

[Martin Patzak (GMX)]

Great! As they say: Don't drink and solder!

Cheers,

Martin

On 10/04/2015 04:25 PM, Nico Bouthoorn wrote:
Ordered a new ds2482-800 chip,   didn't drink the night before and 
replaced/soldered the chip.All is working normally again...


Nico

Nico Bouthoorn wrote:
I've compile the 3.1 version which gives more debug information, 
looks like broken


Konsole output
root@bb01:/opt# /opt/owfs/bin/owserver --i2c=/dev/i2c-1:18 --debug
DEBUG MODE
libow version:
   3.1p0
 DEBUG: ow_daemon.c:(170) main thread id = 3069607936
 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:(102) path=[]
 DEBUG: owlib.c:(77) Global temp limit 0C to 100C (for fake and mock 
adapters)

  CALL: ow_ds2482.c:(167) DS2482 bus address <18> invalid. Will search.
CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 18
 DEBUG: ow_ds2482.c:(516) ok
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 18 cannot 
be reset. Not a DS2482.

CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 19
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 19 cannot 
be reset. Not a DS2482.

CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1A
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1A cannot 
be reset. Not a DS2482.

CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1B
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1B cannot 
be reset. Not a DS2482.

CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1C
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1C cannot 
be reset. Not a DS2482.

CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1D
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1D cannot 
be reset. Not a DS2482.

CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1E
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1E cannot 
be reset. Not a DS2482.

CONNECT: ow_ds2482.c:(396) Found an i2c device at /dev/i2c-1 address 1F
CONNECT: ow_ds2482.c:(422) i2c device at /dev/i2c-1 address 1F cannot 
be reset. Not a DS2482.

 DEBUG: ow_com_close.c:(42) Unimplemented!!!
CONNECT: owlib.c:(145) Cannot detect an i2c DS2482-x00 on /dev/i2c-1:18
DEFAULT: owlib.c:(52) No valid 1-wire buses found
 DEBUG: ow_exit.c:(17) Exit code = 1
  CALL: ow_lib_close.c:(21) Starting Library cleanup
  CALL: ow_lib_stop.c:(22) Clear Cache
 DEBUG: ow_cache.c:(295) Flipping cache tree (purging timed-out data)
 DEBUG: ow_cache.c:(313) flip cache. tdestroy() will be called.
 DEBUG: ow_cache.c:(295) Flipping cache tree (purging timed-out data)
 DEBUG: ow_cache.c:(313) flip cache. tdestroy() will be called.
  CALL: ow_lib_stop.c:(24) Closing input devices
  CALL: ow_lib_stop.c:(26) Closing output devices
  CALL: ow_lib_close.c:(42) Finished Library cleanup
 DEBUG: ow_lib_close.c:(50) Libraries closed



Nico Bouthoorn wrote:


I'm really puzzled,  last night i've got a main power shortage.  I'm running 
the owfs  on a beaglebone (http://fstab.nl/beaglebone) with linux Debian
This was working fine for years.  Now the owserver don't  detect the ds2482-800 
device anymore.
With  /usr/sbin/i2cdetect -r 1 i can see still the device on the i2c bus (18):
owfs version:2.8p15-1
Konsole output
/usr/sbin/i2cdetect -r 1
Konsole output
WARNING! This program can confuse your I2C bus, cause data loss and 
worse! I will probe file /dev/i2c-1 using read byte commands. I will 
probe address range 0x03-0x77. Continue? [Y/n]   0  1  2  3  4 
 5  6  7  8  9  a  b  c  d  e  f 00:  -- -- -- -- -- -- -- 
-- -- -- -- -- --   10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- 
--   20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --   30: -- -- 
-- -- -- -- -- -- -- -- -- -- -- -- -- --   40: -- -- -- -- -- -- -- 
-- -- -- -- -- -- -- -- --   50: -- -- -- -- UU UU UU UU -- -- -- -- 
-- -- -- --   60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --   
70: -- -- -- -- -- -- -- --  I've a second BB running this one 
is still working. Have anybody seen this before or is the device 
broken? Thanks, Nico


--

___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
0623391101


--


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
0623391101


--


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net

Re: [Owfs-developers] Is the owserver working?

[Martin Patzak (GMX)]

start owserver with setting the error-level higher...


On 05/17/2015 08:52 PM, Henry wrote:

...

the same result... but 7 minutes!!!


root@RASPBERRY-3:/usr/src/owfs-3.0p2 date ; owdir / ; date
Вск Май 17 20:42:58 EET 2015
/20.95670E00
/28.FF78011B0400
/28.FF2401630400
/28.FF26C3121400
/28.FF4E061A0400
/28.FFB19F121400
/28.FF55CC121400
/bus.1
/bus.0
/uncached
/settings
/system
/statistics
/structure
/simultaneous
/alarm
Вск Май 17 20:50:01 EET 2015




--
View this message in context: 
http://owfs-developers.1086194.n5.nabble.com/Is-the-owserver-working-tp11334p11346.html
Sent from the OWFS Developers mailing list archive at Nabble.com.

--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Problems with building 2.9p4 none while building the 2.9p3 release

[Martin Patzak (GMX)]

Gregg,

you might want to think about installing Slackware on the RasPi first.

See here: http://rpi.fatdog.eu/

or here: http://docs.slackware.com/howtos:hardware:arm:raspberrypi

(this is of course as I know as well as everybody, you are more familiar 
with Slackware, where everything is normally present)


Cheers,

Martin

On 12/09/2014 05:00 AM, Gregg Levine wrote:

Hello!
It seems building it on the Pi requires that archival releases of the
GNU tools be installed. There were complaints during the running of
the configure script.

However those problems were not present during the building of 2.9p3.

As to why that happened I'm at a loss to explain.

Of course to build in the features and functions for TCL and PHP and
even Python do require the dev portions of these languages. That's an
interesting part of Debian and its relatives that I wasn't completely
aware of.

(That is of course as everyone knows I normally build on Slackware
where everything is normally present.)
-
Gregg C Levine gregg.drw...@gmail.com
This signature fought the Time Wars, time and again.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] unruly temperatures

[Martin Patzak (GMX)]

Well, I guess then it is NOT a software bug then... ;o)
It for sure looked like one...

Would be interesting to understand why it results in this weird behaviour!

Cheers,

Martin


On 09/14/2014 06:25 PM, Nico Bouthoorn wrote:
I've had the same when i left the power pin disconnected (ds18b20), 
now i connect it to ground.


Nico

Martin Patzak (GMX) wrote:
I would check, if the raw data, read from the owfs show that effect 
or if it gets introduced later.
In any case it looks like a software bug to me - I could be wrong, 
but I don't think so ;o)


Think about what changes you made since your last running system 
without the effect.


Martin

On 09/13/2014 02:34 PM, Håkan Elmqvist wrote:
The installation is on a remote island and I can't physically access 
it for now. The server since about two months is a Raspberry Pi B+ 
connected to a wired network. For reliability reasons I have two 
DS9490s connected with a USB-hub powered by a 2 A supply. The Pi 
uses a separate 1 A supply. I use 0,5 mm^2 twisted pair telephone 
wires and soldered connections. The most important sensor, green 
trace, is connected with a 1,5 m cable to one of the adapters. The 
other two are connected to the other adapter with 3 and 10 m cables. 
The sensors use parasitic power.

H
Roberto Spadim skrev 2014-09-13 13:54:

Whats cable distance? Does it use parasite power?




--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers




--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



--
0623391101


--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] unruly temperatures

[Martin Patzak (GMX)]

I would check, if the raw data, read from the owfs show that effect or 
if it gets introduced later.
In any case it looks like a software bug to me - I could be wrong, but I 
don't think so ;o)


Think about what changes you made since your last running system without 
the effect.


Martin

On 09/13/2014 02:34 PM, Håkan Elmqvist wrote:
The installation is on a remote island and I can't physically access 
it for now. The server since about two months is a Raspberry Pi B+ 
connected to a wired network. For reliability reasons I have two 
DS9490s connected with a USB-hub powered by a 2 A supply. The Pi uses 
a separate 1 A supply. I use 0,5 mm^2 twisted pair telephone wires and 
soldered connections. The most important sensor, green trace, is 
connected with a 1,5 m cable to one of the adapters. The other two are 
connected to the other adapter with 3 and 10 m cables. The sensors use 
parasitic power.

H
Roberto Spadim skrev 2014-09-13 13:54:

Whats cable distance? Does it use parasite power?




--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Cannot detect LinkUSBi

[Martin Patzak (GMX)]

Have you tried to disconnect the 1-wire network and connect only to the 
LinkUSB itself?
Sometimes wiring-problems, defective sensors and other hardware related 
problems (like humidity) can cause weird behavior.



On 11/11/2013 07:04 AM, Willard Korfhage wrote:

Doesn't help, I'm afraid. Here's the debug info

DEBUG: ow_ds9097U.c:(287) Attempt 0 of 3 to initialize the DS9097U
DEBUG: ow_ds9097U.c:(381) Send the initial reset to the bus master.
DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.00 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
DEBUG: ow_ds9097U.c:(476) Failed first attempt at resetting baud rate
of bus master /dev/ttyUSB0
DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.00 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
DEBUG: ow_ds9097U.c:(481) Failed second attempt at resetting baud
rate of bus master /dev/ttyUSB0
DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.00 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.00 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.00 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.00 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
DEBUG: ow_ds9097U.c:(476) Failed first attempt at resetting baud rate
of bus master /dev/ttyUSB0
DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.00 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
DEBUG: ow_ds9097U.c:(481) Failed second attempt at resetting baud
rate of bus master /dev/ttyUSB0
DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.00 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.00 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.00 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.00 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
DEBUG: ow_serial_open.c:(174) Cannot power cycle a closed serial port
DEBUG: ow_ds9097U.c:(381) Send the initial reset to the bus master.
DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.00 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
DEBUG: ow_ds9097U.c:(476) Failed first attempt at resetting baud rate
of bus master /dev/ttyUSB0
DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.00 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
DEBUG: ow_ds9097U.c:(481) Failed second attempt at resetting baud
rate of bus master /dev/ttyUSB0
... [keeps going]

I tried to use socat so I could monitor the serial connection:

sudo socat -v -d -d pty,raw,echo=0 file:/dev/ttyUSB0,raw,echo=0,b57600

That creates a pty and a bidirectional passthrough to /dev/ttyUSB0,
echoing the traffic to the screen. I ran owfs with -d /dev/pts/2, for
that is the PTY that socat printed out. Somehow, that ended up resetting
the LinkUSB to 9600 baud, which seems to have been key to getting better
behavior.

By the way, when using socat, I couldn't run owfs with
--link=/dev/pts/2 because I got a cannot access device message even
though I was running as root.

Anyway, now that the LinkUSB is 9600 baud, running

sudo /opt/owfs/bin/owfs --baud=9600 --link=/dev/ttyUSB0 -m /var/lib/1wire

works, partially. The directory shows the structure I expect to see, but
I don't see any devices:

# ls /var/lib/1wire
bus.0  settings  statistics  structure  system  uncached

There is a temperature sensor on it, so I would expect to see something.

On 11/10/2013 12:54 PM, Don Veino wrote:

What happens if you try -d vs --link, as in following?

sudo /opt/owfs/bin/owfs -d /dev/ttyUSB0 -m /var/lib/1wire

I have a LinkUSB (non-i) and use that device nomenclature with
owserver and it works fine with 2.9p0-1 on Arch Linux ARM.


--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and 

Re: [Owfs-developers] Cannot detect LinkUSBi

[Martin Patzak (GMX)]

Willard,

please show us the log, while you plug in the LinkUSB into your machine!
Maybe your ttyUSB0 is already taken by a different device?

Martin

On 11/09/2013 11:12 PM, Willard Korfhage wrote:

I am rebuilding a machine that ran owfs, so I installed Ubuntu 12.04,
then downloaded owfs 2.9p1 and built it in the usual way, following my
notes from when I did the same thing with 2.8p14. I did

./configure --enable-owfs --enable-owhttpd --enable-usb

when configuring before building. When I try to run it, it fails

sudo /opt/owfs/bin/owfs --link=/dev/ttyUSB0 -m /var/lib/1wire
DEFAULT: ow_link.c:(242) LINK detection error
DEFAULT: ow_link.c:(251) LINK detection error
DEFAULT: ow_link.c:(242) LINK detection error
DEFAULT: ow_link.c:(251) LINK detection error
DEFAULT: ow_link.c:(242) LINK detection error
DEFAULT: ow_link.c:(251) LINK detection error
DEFAULT: ow_link.c:(242) LINK detection error
DEFAULT: ow_link.c:(251) LINK detection error
DEFAULT: owlib.c:(56) No valid 1-wire buses found

As an experiment, I downloaded 2.8p14, built it, and that fails with
LINK detection errors, too. When I ran the machine before, it was
running on an older version of Ubuntu, probably 11.10, so looks like
some Linux change might be responsible for the current problems.

Any suggestions on what to do? I tried 2.9p1 with a DS9490R that I had
around, and that seemed to be ok.


--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Failing DS1820

[Martin Patzak (GMX)]

You measure down to 3 degrees and deeper? So could humidity over time 
have created corrosion in the connection of the sensor?



On 10/04/2013 08:28 AM, Håkan Elmqvist wrote:

It is buspowered with Vdd pin grounded and has worked properly for about
two years. There are only two branches, 4 sensors with about 25 m of
twisted telephone wire.
H

2013-10-04 07:45, Markus Gaugusch skrev:

Hi Håkan,

How did you connect it? Is it bus powerd (Vdd pin should be grounded
in that case) or does it use an extra power supply? How is the
topology of your network (length, number of sensors, how many
branches/how long)?

regards,
Markus

On Oct 3, Håkan Elmqvist hak...@smeden.org wrote:


I have a remote DS1820 that consistently reads exactly 85 degrees C,
both in cached and uncached modes, when the real reading should be
around 3 degrees.
Has anyone seen this kind of failure before, is there anything I can do
about it remotely or do I have to go there and put in a new sensor?
Thanks in advance for any tip
H





--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Need a new adaptor. Some thoughts?

[Martin Patzak (GMX)]

Bruce,

a Shop with a wide selection for 1-wire chips is:

http://www.fuchs-shop.com/en/shop/17/

I use the LinkUSB and I am very happy with it. I run a powered network 
of about 15 temp-sensors and 3 IO-chips, which is driving my home 
heating system.


Cheers
Martin

On 09/28/2013 07:37 PM, brucek wrote:
Well, I tracked down my ow network failure to the melted DS9490R.  It 
looks like it could have actually been a fire risk.
Anyway, I see new DS9490R's at Newark for $33.81 + s/h ($20 min), and 
on eBay for $66.00 (really?)
I also see a Bulgarian one based on Chipset: FT232RL and DS2480B with 
terminals for about $33 with shipping, and a Chinese one USB9097 with 
3.5mm TRS for $22.50 with shipping.

Anyone have any experience with these cheapo adaptors?
Bruce


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Need a new adaptor. Some thoughts?

[Martin Patzak (GMX)]

I just checked the data sheet of the LinkUSB and it does not have a 
1-wire chip at all but rather emulates the DS2480 - here an excerpt:


DS2480B/9097U Emulation
The LinkUSBTM is programmed to closely emulate a Dallas DS2480B serial 
port to
1-Wire line driver so that existing software can use it without 
modification. (The
DS2480B is the basis for the Dallas DS9097 series of 1-Wire adapters.) 
This allows the
LinkUSBTM to be used in place of the Dallas DS2480B in most cases where 
increased
performance or reliability is required. Some DS2480B functions are not 
emulated by the

LinkUSBTM, as described below.


On 09/29/2013 11:22 AM, Vajk Fekete wrote:
The key piece of information is, that ds9490 uses the ds2490 chip. 
Which is kinda discontinued by dallas/maxim. At a point they stated 
they have made a huge lot that will last years, and stopped 
production. They may have restarted production, or are just keeping 
price high enough to fulfill the prediction stock will last for years


Your best bet is to get any clone that uses the ds2480 chip and some 
sort of usb serial port. As far as I know, the ds24080 is abou the 
same functionality as the ds2490, just missing the native usb interface.


Hope the members with low level programming experience will 
confirm/debate that the 2480 is same level as 2490.


all best,

Vajk


On Sun, Sep 29, 2013 at 9:18 AM, Martin Patzak (GMX) 
martin.pat...@gmx.de mailto:martin.pat...@gmx.de wrote:


Bruce,

a Shop with a wide selection for 1-wire chips is:

http://www.fuchs-shop.com/en/shop/17/

I use the LinkUSB and I am very happy with it. I run a powered
network of about 15 temp-sensors and 3 IO-chips, which is driving
my home heating system.

Cheers
Martin

On 09/28/2013 07:37 PM, brucek wrote:

Well, I tracked down my ow network failure to the melted
DS9490R.  It looks like it could have actually been a fire risk.
Anyway, I see new DS9490R's at Newark for $33.81 + s/h ($20 min),
and on eBay for $66.00 (really?)
I also see a Bulgarian one based on Chipset: FT232RL and DS2480B
with terminals for about $33 with shipping, and a Chinese one
USB9097 with 3.5mm TRS for $22.50 with shipping.
Anyone have any experience with these cheapo adaptors?
Bruce



--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most 
from
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net  
mailto:Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers




--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get
the most from
the latest Intel processors and coprocessors. See abstracts and
register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
mailto:Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers




--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Data Display

[Martin Patzak (GMX)]

Ryan,

I use MBLogic 
http://sourceforge.net/projects/mblogic/?source=directory to display 
my home heating system. I display the data of different 1-wire devices 
via html in a process view.
To generate the html-code I use it's built-in and customizable html-page 
generator.


I display temperature-sensors, pumps, levers and doors.

The 1-wire part did not come with MBLogic and I wrote some code, that I 
will share with you, if you are interested.


Cheers,

Martin
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] problem with owfs/owserver on raspberry pi

[Martin Patzak (GMX)]

Paul,

thats a good idea. It really helps when people just get started or 
change hardware.
I tried to find Mark's error, and so I started owfs while my LinkUSB was 
unplugged and I got the same result he had:

no error and no daemon was started!

So I barked up the wrong tree, until you pointed out he wrongly used usb 
instead of the serial interface.


Thanks,

Martin

On 06/16/2013 04:15 PM, Paul Alfille wrote:
Thats great, but let me see if a better diagnostic message can be 
generated. Seems like too easy an error to make.


Paul


On Sat, Jun 15, 2013 at 11:26 PM, Mark Phillips mphil...@unca.edu 
mailto:mphil...@unca.edu wrote:


Paul,

Thank you very much!  That was the problem.  I have a lot of
experience with Linux, and with software development, but not so
much hardware knowledge, and I naively assumed that since my
LinkUSB has USB in its name, and connects to the computer (the
RPi in my case) with a USB connector, that it must be a USB
device.  When I changed my owfs.conf file to say server: device =
/dev/ttyUSB0 instead of server: usb = all, everything started
working beautifully!

--Mark


On Sat, Jun 15, 2013 at 9:03 PM, Paul Alfille
paul.alfi...@gmail.com mailto:paul.alfi...@gmail.com wrote:

You have it set up for a USB bus master, but that really means
the DS9490R USB one made by Maxim. I think you really have a
serial type (Link or DS9097U) connected to a USB-serial
connector (the FTDI chip)

Depending on which actual bus master you are using, it should be
owserver -d /dev/ttyUSB0
or
owserver --link=/dev/ttyUSB0




--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
mailto:Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers




--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
mailto:Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers




--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Fwd: problem with owfs/owserver on raspberry pi

[Martin Patzak (GMX)]

Hello Mark,

I did not forget about you :-)
It is early Saturday morning here ;-)

When I start owfs without the LinkUSB plugged in I also get no feedback 
and there is no daemon started, so I suspect this is the problem - or 
one of them:-)

On 06/15/2013 05:36 AM, Mark Phillips wrote:
 Martin,

 I would be interested in hearing about any details you find on your 
 home system this weekend, especially in regard to FTDI drivers.  I am 
 still having the same problem with owfs on my RPi.  I still don't know 
 what's causing the problem, but for various reasons I am starting to 
 suspect that it has to do with the drivers.
check the syslog, when plugging in the LinkUSB either directly into one 
of the two USB ports of the raspi or inta a USB-hub that is connected to 
the raspi (that's what I have here).
For that give the command
 sudo tail -f /var/log/syslog

It will keep the terminal open and print whatever enters the syslog 
file, so you don't have to constantly read.
I am connected over ssh to the raspi, so I just open different sessions, 
for different commands. I would suggest you also open multiple terminals 
and leave e.g. syslog tailing active for now.

So, when I plug in the LinkUSB I get the following syslog entry:



Jun 15 08:57:45 razmataz kernel: [  123.288409] usb 1-1.3.7: new 
full-speed USB device number 8 using dwc_otg
Jun 15 08:57:45 razmataz kernel: [  123.396540] usb 1-1.3.7: New USB 
device found, idVendor=0403, idProduct=6001
Jun 15 08:57:45 razmataz kernel: [  123.396571] usb 1-1.3.7: New USB 
device strings: Mfr=1, Product=2, SerialNumber=3
Jun 15 08:57:45 razmataz kernel: [  123.396588] usb 1-1.3.7: Product: 
FT232R USB UART
Jun 15 08:57:45 razmataz kernel: [  123.396601] usb 1-1.3.7: 
Manufacturer: FTDI
Jun 15 08:57:45 razmataz kernel: [  123.396614] usb 1-1.3.7: 
SerialNumber: A800bXHr
Jun 15 08:57:45 razmataz kernel: [  123.414099] ftdi_sio 1-1.3.7:1.0: 
FTDI USB Serial Device converter detected
Jun 15 08:57:45 razmataz kernel: [  123.414314] usb 1-1.3.7: Detected 
FT232RL
Jun 15 08:57:45 razmataz kernel: [  123.414336] usb 1-1.3.7: Number of 
endpoints 2
Jun 15 08:57:45 razmataz kernel: [  123.414351] usb 1-1.3.7: Endpoint 1 
MaxPacketSize 64
Jun 15 08:57:45 razmataz kernel: [  123.414365] usb 1-1.3.7: Endpoint 2 
MaxPacketSize 64
Jun 15 08:57:45 razmataz kernel: [  123.414379] usb 1-1.3.7: Setting 
MaxPacketSize 64
Jun 15 08:57:45 razmataz kernel: [  123.415414] usb 1-1.3.7: FTDI USB 
Serial Device converter now attached to ttyUSB0

-

Is your output the same?
IF NO, then this is the problem, or one of them :-) in that case try

IF YES:

In the last line it says ... now attached to ttyUSB0 it could say 
something else like ttyUSB1 or so. In fact under some circumstances 
reconnecting did increase that number - but I am not sure if this was 
happening on the raspi.

Now check, that your LinkUSB - that is actually the FTDI USB to serial 
chip - is alive and kickin':

 sudo cat /dev/ttyUSB0

should come back with many lines:

 LinkUSB V1.4

then Ctrl-C the command to stop the connection



 Actually, it seems to me that I am having (at least) two distinct 
 problems.

 The first problem is that owserver exits immediately upon being 
 started.  I suspect that this has to do with driver issues because it 
 works correctly when I change my /etc/owfs.conf file to use fake 
 devices --- it's only when owfs.conf is configured to use USB that it 
 crashes.
If the above all worked then you might start owfs without owfs.conf for now:

 owfs -d /dev/ttyUSB0 -m /mnt/1wire --error_level=2 --foreground

the directory /mnt/1wire I created before with my local users privileges 
like so (there is no reason to start owfs with sudo):

 ls -al /mnt/

drwxr-xr-x  2 mnm  mnm  4096 Jan  6 13:18 1wire
.

If you got that far, everything should work now! :-)

Martin


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] problem with owfs/owserver on raspberry pi

[Martin Patzak (GMX)]

if one creates a directory 1-wire with ones username group and 
permissions to read and write sudo should not be necessary.

Maybe you didn't create a directory for the fuse-system at all?

Martin

On 06/10/2013 10:32 AM, Mick Sulley wrote:
Have you tried running with sudo, that is usually necessary when using 
a USB device on owfs


Mick

On 10/06/13 04:53, Mark Phillips wrote:

Hi,

I'm new to owfs and am trying to use it with a LinkUSB and two 
temperature sensors on a Raspberry Pi.  I've gotten the owfs package 
installed via apt-get install owfs, and I edited /etc/owfs.conf 
according to some examples I've found on the web.  But when I try to 
run either owfs or owserver, both programs terminate with no error 
messages.  I've tried setting error_level=9 in /etc/owfs.conf, and 
also passing --error_level=9 on the command line, to no avail.


Can someone give me a tip as to how I can get owserver/owfs to give 
me some error output so that I can get some clues as to what is going 
wrong?


Thanks!



--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] problem with owfs/owserver on raspberry pi

[Martin Patzak (GMX)]

error messages go to syslog, unless you specify --foreground (I hope its 
written right, check the man page please), in which case you get all 
message directly to the terminal and the terminal stays connected to the 
daemon.
error-level=9 delivers a LOT of messages! Try a lower number like 2 or 3 
to get the essential messages.


Martin


On 06/10/2013 05:53 AM, Mark Phillips wrote:

Hi,

I'm new to owfs and am trying to use it with a LinkUSB and two 
temperature sensors on a Raspberry Pi.  I've gotten the owfs package 
installed via apt-get install owfs, and I edited /etc/owfs.conf 
according to some examples I've found on the web.  But when I try to 
run either owfs or owserver, both programs terminate with no error 
messages.  I've tried setting error_level=9 in /etc/owfs.conf, and 
also passing --error_level=9 on the command line, to no avail.


Can someone give me a tip as to how I can get owserver/owfs to give me 
some error output so that I can get some clues as to what is going wrong?


Thanks!



--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] problem with owfs/owserver on raspberry pi

[Martin Patzak (GMX)]

 could be wrong?  I 
don't understand why I am not seeing any error output at all.


Thanks again!

--Mark




On Mon, Jun 10, 2013 at 5:55 AM, Martin Patzak (GMX) 
martin.pat...@gmx.de mailto:martin.pat...@gmx.de wrote:


error messages go to syslog, unless you specify --foreground (I
hope its written right, check the man page please), in which case
you get all message directly to the terminal and the terminal
stays connected to the daemon.
error-level=9 delivers a LOT of messages! Try a lower number like
2 or 3 to get the essential messages.

Martin


On 06/10/2013 05:53 AM, Mark Phillips wrote:

Hi,

I'm new to owfs and am trying to use it with a LinkUSB and two
temperature sensors on a Raspberry Pi.  I've gotten the owfs
package installed via apt-get install owfs, and I edited
/etc/owfs.conf according to some examples I've found on the web.
 But when I try to run either owfs or owserver, both programs
terminate with no error messages.  I've tried setting
error_level=9 in /etc/owfs.conf, and also passing
--error_level=9 on the command line, to no avail.

Can someone give me a tip as to how I can get owserver/owfs to
give me some error output so that I can get some clues as to what
is going wrong?

Thanks!




--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net  
mailto:Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers



--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
mailto:Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers




--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Monitoring AC power lines

[Martin Patzak (GMX)]

Hi Giulio,

a simple solution would be, if you use a current sensor based on the 
hall effect priciple. This type of sensor gives you a voltage 
proportional to the current, which in return can be monitored a 1wire 
voltage sensor. Those sensors can monitor quite high currents (up to 
200A), but I don't know if they can handle 240VAC! You might have to 
search for some specs on those.


Alternatively you can have a coil around the a strand of the a cable you 
want to measure and again get a voltage (induction) proportional to the 
current in the strand.


Hope this helps a bit,

Martin


On 05/24/2013 08:27 PM, Giulio Carabetta wrote:

Hello!

I'm thinking about a new project, about monitoring AC power lines, in 
industrial environment (tipically AC 220@50Hz, hi current...).


I have some little experience with owfs, and I'm reading this list 
from a lot, so I was thinking about a solution with a linux based 
small hardware (like raspberry or arduino or odroid, ecc).
I remember I read something like this, maybe with DS2450 (no longer 
available?) or also with DS2438. But I don't know how this is 
applicable, for the measurement and for an industrial production area.


Can be better to move to i2c? I've seen some power and energy 
measurement IC, even from Maxim, with I2C bus, but it will be totally 
new for me.


And, to make more complicated all, I must admit that I'm not so strong 
on the electric/electronic side... :)


Any suggestion will be very appreciated

Many thanks

Giulio


--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may


___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] OWFS + W1 on Raspberry Pi

[Martin Patzak (GMX)]

yes, I use a powered hub from the list of complient powered hubs. The 
layout on the raspi circuit board for power supply of the usb is not 
that good. So you loose quite some voltage on the printed circuits.

Hence the recommendation to use a powered usb hub.

It is possible and safe to use the same power supply you power the raspi 
with, to power the usb-hub externally. Use only a powered hub from the 
recommended and tested list for raspi. As to directly power the devices 
themselves, I have no experience with, but there is a link in my 
previous post to the guys over at raspi central (around where I shorted 
my USB fuses on the raspi with a soldering iron) where they talk about 
exactly and why not to do it and how to do it, if one still wants or has 
to do it :o)

I did post my hardware in previous emails - so you probably found them 
already.

The trick with disabling the eth0 was/is, that usb and ethernet is 
integrated in one and the same chip on the raspi, and the driver for it 
was/is faulty and caused hard hangs on the raspi. Thats why the 
cecommendation was/is to disable ethernet and use a usb wifi stick - 
again from the recommended list - in the externally powered hub.

It's actually quite simple ;-)



On 02/16/2013 02:51 PM, Attila wrote:
 Oops, forgot to tell - I found your earlier comments, and seems you are
 using a powered USB hub.
 Does anyone know, if it is safe to power USB devices directly from the
 same power supply I use to power the RasPi?

 Eth0 - why you had to disable? I found a problem, when eth0 disconnect
 (cable disconnect for example) stopped USB working, but after I disabled
 the daemon (I cant recall its name, its reposnsible to alter networking
 based on connect-disconnect events), it was resolved.
 So now I have problem only on reboots.


--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] OWFS + W1 on Raspberry Pi

[Martin Patzak (GMX)]

Hello Attila,

what kind of USB master did you use?
I am using the LinkUSBi and it is working very stable for more than 3 
months on end (24/7).

I did post some settings I did to the raspi to make it more stable, and 
I can 'dig out' those old posts here, in case you can't find them.

However things might have been changed since updates of the raspi 
packages have been made and I do NOT upgrade, once I have found a stable 
platform (I am running my house heating system on it, so stability is key)

Cheers,

Martin


On 02/16/2013 08:52 AM, Attila wrote:
 Greetings,

 After several tries I found that my USB 1-wire master is not working
 reliable on Raspberry Pi - seems in some cases USB bus power is not
 enough (syslog tells this).
 Before going to use an externally powered USB hub, I tried to use GPIO
 bitbang method to drive 1-wire.
 I used w1 libary (w1-gpio and w1-therm), but found that OWFS cannot
 really work with it.
 I tried

 modprobe w1-gpio
 modprobe w1-therm
 owserver --w1 -p 4300
 owhtpd -s 4300 -p 80

 But when I try to connect via HTTP, RPi freezes, and I have to unplug it.
 Same if I use owfs instead of owhttpd, when I try to go to the mount point.

 In the same time I'm able to see the files what w1 mounts
 (/sys/bus/w1/devices) and read values without problem (But I have to
 say, one time it was frozen using this method as well)

 I upgraded kernel, packages, but no help.

 What can be wrong?


 Thanks,
 Attila


 --
 The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
 is your hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials, tech docs,
 whitepapers, evaluation guides, and opinion stories. Check out the most
 recent posts - join the conversation now. http://goparallel.sourceforge.net/



 ___
 Owfs-developers mailing list
 Owfs-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

[Owfs-developers] OWFS on tmpfs

[Martin Patzak (GMX)]

Hallo all,

I am trying to run OWFS on tmpfs, but I do not succeed.
I created a mount entry in fstab:

tmpfs /mnt/1wire tmpfs nodev,nosuid,size=3M,uid=1004,gid=1005 0 0

the uid and gid are the ones of my own user


then I mount and can check the success with df -k which list /mnt/1wire 
as a tmpfs file system. As well as listing ls -al /mnt/ results i a 
small t for tmpfs at the entry 1wire

when I start now OWFS it does not use the tmpfs created, but seems to 
unmount and remount.

Is there a way to have OWFS use tmpfs and how?

I need it, because I am running of raspi with only a sd-card attached.

Thanks,

Martin

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] OWFS on tmpfs

[Martin Patzak (GMX)]

I see! Thanks Chris for the quick reply!!!

Btw. what does HTH mean?

Martin


--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] OWFS on tmpfs

[Martin Patzak (GMX)]

got it:

HTH - hope that helps

YID - yes, it did

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Voltage sensor

[Martin Patzak (GMX)]

yes, that might be a lot - but it depends:
as I know from travelling, in the US everybody runs their outside door 
light ALL night, EVERY night!!!

Thanks for pointing out a solution to save power with caps though!

On 12/05/2012 04:45 PM, Roberto Spadim wrote:
 1 watt that's energy lost in temperature!
 use a two caps divider and a lower resistence


 2012/12/5 Martin Patzak (GMX) martin.pat...@gmx.de
 mailto:martin.pat...@gmx.de

 Silvano,

 as Google is my friend, it can be Yours too!

 Look what I found:

 http://ruggedcircuits.com/html/circuit__26.html

 Hope it helps,

 Martin


 On 12/04/2012 06:08 PM, Silvano Gai wrote:
   I need to sense the presence of AC power (110 Volts) in six different
   places.
   Any 1Wire sensor recommended?
   Power detection (on/off) is acceptable, voltage measurement will
 be better
  
   Thanks
  
   -- Silvano
  
  
 
 --
   LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
   Remotely access PCs and mobile devices and provide instant support
   Improve your efficiency, and focus on delivering more value-add
 services
   Discover what IT Professionals Know. Rescue delivers
   http://p.sf.net/sfu/logmein_12329d2d
   ___
   Owfs-developers mailing list
   Owfs-developers@lists.sourceforge.net
 mailto:Owfs-developers@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/owfs-developers
  

 
 --
 LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
 Remotely access PCs and mobile devices and provide instant support
 Improve your efficiency, and focus on delivering more value-add services
 Discover what IT Professionals Know. Rescue delivers
 http://p.sf.net/sfu/logmein_12329d2d
 ___
 Owfs-developers mailing list
 Owfs-developers@lists.sourceforge.net
 mailto:Owfs-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/owfs-developers




 --
 Roberto Spadim
 Spadim Technology / SPAEmpresarial


 --
 LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
 Remotely access PCs and mobile devices and provide instant support
 Improve your efficiency, and focus on delivering more value-add services
 Discover what IT Professionals Know. Rescue delivers
 http://p.sf.net/sfu/logmein_12329d2d



 ___
 Owfs-developers mailing list
 Owfs-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/owfs-developers

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Voltage sensor

[Martin Patzak (GMX)]

Silvano,

as Google is my friend, it can be Yours too!

Look what I found:

http://ruggedcircuits.com/html/circuit__26.html

Hope it helps,

Martin


On 12/04/2012 06:08 PM, Silvano Gai wrote:
 I need to sense the presence of AC power (110 Volts) in six different
 places.
 Any 1Wire sensor recommended?
 Power detection (on/off) is acceptable, voltage measurement will be better

 Thanks

 -- Silvano

 --
 LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
 Remotely access PCs and mobile devices and provide instant support
 Improve your efficiency, and focus on delivering more value-add services
 Discover what IT Professionals Know. Rescue delivers
 http://p.sf.net/sfu/logmein_12329d2d
 ___
 Owfs-developers mailing list
 Owfs-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Raspberry pi running Raspbian and owfs

[Martin Patzak (GMX)]

Hi PeO,

for starting owserver, refer to the man page - the example there is:

EXAMPLE
owserver -p 3001 -d /dev/ttyS0 runs owserver on tcp port 3001 
and connects to a physical 1-wire bus on a serial port.

So there is no need for an init.d script.

My latest version of owfs is 2.8p15 running raspian wheezy. What version 
of raspian are You running, since You have owfs-2.8p20.

For the perl module you have to install the libownet-perl package.

Cheers,

Martin


On 11/15/2012 05:32 PM, PeO wrote:

 Hello!

 New to OWFS trying to set up a House Control System on RPi and ran into some
 problems. Under Ubuntu I manage to start OWNet and got it working with
 Perlscript but under Raspbian i can,t start the services with service
 owserver start. There is no scripts in /etc/init.d/ concerning owfs.  I
 have the latest distribution, owfs-2.8p20. Any idea on how to progress?

 /PeO



 Guy COLIN wrote:

 Hello,

 This simple message, just to say that owfs is running fine on Raspbian.
 I have read many posts here about the Raspberry pi but none saying this
 simple
 thing:
 Raspberry pi + Raspbian + owfs run directly out of the box:
 sudo apt-get install owfs  # to install it
 then edit /etc/owfs.conf to your needs.
 That's all, it works!
 The owfs package contains the version 2.8p15
 I use owfs from 5 years now and I'm planning to move my home 1wire network
 which
 is driving my central heating, on the Raspberry pi.
 Just the script /etc/init.d/owfs is missing only owserver, owhttpd, owftpd
 are
 included and these 3 services started at boot. But it's easy to build this
 script by copying one of these 3. Now when I boot the 4 services are
 started.

 Again thanks Paul and all the community for this fantastic software.
 --
 Guy


 --
 LogMeIn Central: Instant, anywhere, Remote PC access and management.
 Stay in control, update software, and manage PCs from one command center
 Diagnose problems and improve visibility into emerging IT issues
 Automate, monitor and manage. Do more in less time with Central
 http://p.sf.net/sfu/logmein12331_d2d
 ___
 Owfs-developers mailing list
 Owfs-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/owfs-developers




--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Raspberry pi running Raspbian and owfs

[Martin Patzak (GMX)]

yes, uname -r gives me too 3.2.27+

How come your owfs version is 2.8p20? Did you install it via apt-get or 
aptitude?


On 11/15/2012 08:20 PM, Per-Ola Roos wrote:
 Hello Martin!

 Thanks for your quick respons. I will tried to start owserver as you
 suggested but no success yet.

 I downloaded 2012-10-28 -wheezy-raspian.zip torrent and by login it states
 Linux raspberrypi 3.2.27+.

 /PeO


 - Original Message -
 From: Martin Patzak (GMX)martin.pat...@gmx.de
 To: OWFS (One-wire file system) discussion and help
 owfs-developers@lists.sourceforge.net
 Sent: Thursday, November 15, 2012 7:56 PM
 Subject: Re: [Owfs-developers] Raspberry pi running Raspbian and owfs


 Hi PeO,

 for starting owserver, refer to the man page - the example there is:

 EXAMPLE
 owserver -p 3001 -d /dev/ttyS0 runs owserver on tcp port 3001
 and connects to a physical 1-wire bus on a serial port.

 So there is no need for an init.d script.

 My latest version of owfs is 2.8p15 running raspian wheezy. What version
 of raspian are You running, since You have owfs-2.8p20.

 For the perl module you have to install the libownet-perl package.

 Cheers,

 Martin


 On 11/15/2012 05:32 PM, PeO wrote:

 Hello!

 New to OWFS trying to set up a House Control System on RPi and ran into
 some
 problems. Under Ubuntu I manage to start OWNet and got it working with
 Perlscript but under Raspbian i can,t start the services with service
 owserver start. There is no scripts in /etc/init.d/ concerning owfs.  I
 have the latest distribution, owfs-2.8p20. Any idea on how to progress?

 /PeO



 Guy COLIN wrote:

 Hello,

 This simple message, just to say that owfs is running fine on Raspbian.
 I have read many posts here about the Raspberry pi but none saying this
 simple
 thing:
 Raspberry pi + Raspbian + owfs run directly out of the box:
 sudo apt-get install owfs  # to install it
 then edit /etc/owfs.conf to your needs.
 That's all, it works!
 The owfs package contains the version 2.8p15
 I use owfs from 5 years now and I'm planning to move my home 1wire
 network
 which
 is driving my central heating, on the Raspberry pi.
 Just the script /etc/init.d/owfs is missing only owserver, owhttpd,
 owftpd
 are
 included and these 3 services started at boot. But it's easy to build
 this
 script by copying one of these 3. Now when I boot the 4 services are
 started.

 Again thanks Paul and all the community for this fantastic software.
 --
 Guy


 --
 LogMeIn Central: Instant, anywhere, Remote PC access and management.
 Stay in control, update software, and manage PCs from one command center
 Diagnose problems and improve visibility into emerging IT issues
 Automate, monitor and manage. Do more in less time with Central
 http://p.sf.net/sfu/logmein12331_d2d
 ___
 Owfs-developers mailing list
 Owfs-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/owfs-developers




 --
 Monitor your physical, virtual and cloud infrastructure from a single
 web console. Get in-depth insight into apps, servers, databases, vmware,
 SAP, cloud infrastructure, etc. Download 30-day Free Trial.
 Pricing starts from $795 for 25 servers or applications!
 http://p.sf.net/sfu/zoho_dev2dev_nov
 ___
 Owfs-developers mailing list
 Owfs-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/owfs-developers


 --
 Monitor your physical, virtual and cloud infrastructure from a single
 web console. Get in-depth insight into apps, servers, databases, vmware,
 SAP, cloud infrastructure, etc. Download 30-day Free Trial.
 Pricing starts from $795 for 25 servers or applications!
 http://p.sf.net/sfu/zoho_dev2dev_nov
 ___
 Owfs-developers mailing list
 Owfs-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/owfs-developers


--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Problems to switch PIO on DS2408

[Martin Patzak (GMX)]

I confirm. Furthermore is interesting, that when e.g. switching Bit 0 
with PIO.BYTE setting to 1 the PIO.0 does NOT get updated as it 
normally is the case; it stays on 0!


On 11/05/2012 09:49 AM, Silvio Schmieder wrote:

 Yes, exactly. If I send the correct BYTE value how I wrote in post before,
 the PIO's switches how it should.


 Paul Alfille-2 wrote:

 If I understand you correctly, you can set specific PIO channels with the
 PIO.BYTE, but not via PIO.n, correct?


--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Problems to switch PIO on DS2408

[Martin Patzak (GMX)]

and it does switch the correct outputs. So there is no 
big-little-endian-mixup at this particular point!

On 11/05/2012 12:32 PM, Silvio Schmieder wrote:

 Yes, if you read a single PIO the state is always '0', but reading PIO.BYTE
 shows the correct BYTE value.


 Martin Patzak (GMX) wrote:

 I confirm. Furthermore is interesting, that when e.g. switching Bit 0
 with PIO.BYTE setting to 1 the PIO.0 does NOT get updated as it
 normally is the case; it stays on 0!


 On 11/05/2012 09:49 AM, Silvio Schmieder wrote:

 Yes, exactly. If I send the correct BYTE value how I wrote in post
 before,
 the PIO's switches how it should.


 Paul Alfille-2 wrote:

 If I understand you correctly, you can set specific PIO channels with
 the
 PIO.BYTE, but not via PIO.n, correct?


 --
 LogMeIn Central: Instant, anywhere, Remote PC access and management.
 Stay in control, update software, and manage PCs from one command center
 Diagnose problems and improve visibility into emerging IT issues
 Automate, monitor and manage. Do more in less time with Central
 http://p.sf.net/sfu/logmein12331_d2d
 ___
 Owfs-developers mailing list
 Owfs-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/owfs-developers




--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] simulation mode, some thoughts

[Martin Patzak (GMX)]

well so far I am using the ability to set temperatures and inputs at 
will, just by writing to the files in the fuse-filesystem (which is a 
regular filesystem only of course), in order to test scenarios that 
would be difficult or dangerous to test in real life :)

For example over-temperature in the water buffer of my wood burning 
oven, or over-temperature in the floor-heating due to a defect 
mixer-valve, or failing temperature sensors, etc.

Martin

P.S. since your nickname seems to be Giggls, I wonder if you are 
familiar with the giggle-loop?

On 11/05/2012 01:48 PM, Sven Geggus wrote:
 Martin Patzak (GMX)martin.pat...@gmx.de  wrote:

 So, I did not use fake-mode at all. I am not even running owfs on my
 test-machine. Again it only works if you use the fuse-filesystem!

 Unfortunately not applicable to my use-case. I'm currently using the c-api
 in my Software.

 Interesting solution anyway because at least in your case it would be
 possible to set up some kinf of unit testing by just using inotify.

 Sven




--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers