Maestro Stefano, questo sembra bellissimo! :-)
On 14.10.20 16:13, Stefano Miccoli via Owfs-developers wrote:
> A more succinct way would be:
>
> str(x).encode()
>
> In fact the outer call to ‘bytes’ in 'bytes(str.encode(str(x)))' is a
> no-op, and python strings are objects which have an ‘encode'
👍 Stefano, thank you for the summary, most appreciated 👍
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
is meaningless to me. The path is not wrong so is it
> complaining about writing a single byte?
>
> Thanks again.
>
> On 8/24/2020 4:33 PM, Dennis Putnam wrote:
>> Thanks to everyone that replied. I was not aware of pyownet. I will
>> look into that and rewrite my code
e:
>> Thanks to everyone that replied. I was not aware of pyownet. I will
>> look into that and rewrite my code to use it.
>>
>> On 8/24/2020 11:47 AM, Martin Patzak wrote:
>>> For python I would highly recommend you use the library *pyownet *by
>>> Stefan
n2 didn't seem to care, that threw me for a while.
>
> Also from command line you can use the commands from ow-shell, so
> owdir lists all devices, owread 28.A59F9D0B/latesttemp reads the
> value from that device.
>
> Hope that helps.
>
> Mick
>
>
> On 24/08/
For python I would highly recommend you use the library *pyownet *by
Stefano Miccoli
/https://github.com/miccoli/pyownet/
/using Fuse can lead to weird problems... (not saying that it is the
reason in your specific case)
or you can use the buil-in functions in owserver owread/owwrite/owdir
inste
Sorry Mick, my notes were not detailed enough. Glad you got your system
back on track.
I cannot confirm that CRC16 goes up by 8 - I used exactly your lines and
got the CRC16 go up by one exactly every time.
First, someone familiar with the code should try to find the source of
the bug.
Maybe we fi
this point. If you can tell me how to
> install it I will test it out.
>
> Thanks
>
> Mick
>
>
> On 16/08/2020 17:29, Stefano Miccoli via Owfs-developers wrote:
>> The CRC16 error could be related
>> to https://github.com/owfs/owfs/issues/55
>>
>>
ia Owfs-developers wrote:
>> The CRC16 error could be related
>> to https://github.com/owfs/owfs/issues/55
>>
>> The version on master is already patched, and will be released in
>> 3.2p4. If possible check if the current version on master works as
>> expected.
&
I tested it and I can confirm that writing to
/uncached/simultaneous/voltage increases the CRC16_error by one.
Mick, do you have voltage devices on your network? (I hope it is not a
stupid question)
I don't have such devices, so I cannot test this further...
Greetings,
Marty
On 13.08.20 01:04, M
On 09.08.20 11:34, Mick Sulley wrote:
>
> CRC16_tries 11768
> CRC16_errors 11768
>
you should not have near that amount of CRC errors
read the errors after every module reading or writing to find out what
causes those errors
>
> Time to do some reading of the docs...
>
yeah, enj
ccess higher than tries.0? I do
not know...)
tries.0 139228047
tries.1 1077 (one thousand re-tries in a couple
of years reading 25 sensors every 30 seconds)
tries.2 6 (six second re-tries... not bad
ey? ;-)
CRC16_tries 81858524
CRC16_err
the re-tries that occur in
case of a CRC16 error /tries.1 and /tries.2
On 09.08.20 10:49, Martin Patzak wrote:
> An operation will be retried three times - resulting in an increased
> operation time - which will be logged in /statistics/*read*/tries.x -
> where 0 is the first re-try or /s
documentation on this stuff, I can't find anything.
>
> Mick
>
> On 08/08/2020 08:46, Martin Patzak wrote:
>> Thanks Mick, great summary.
>>
>> Let me add to 4), that you only see the 0.7 sec delay, because you
>> read in a busy loop.
>> I read only every 30
f, I can't find anything.
>
> Mick
>
> On 08/08/2020 08:46, Martin Patzak wrote:
>> Thanks Mick, great summary.
>>
>> Let me add to 4), that you only see the 0.7 sec delay, because you
>> read in a busy loop.
>> I read only every 30 seconds and I neve
Thanks Mick, great summary.
Let me add to 4), that you only see the 0.7 sec delay, because you read
in a busy loop.
I read only every 30 seconds and I never see a delay.
But timing your reads is a good practice because this way you catch
retries and maybe bus or sensor problems.
Additionally you
ot the
> faintest idea why that should be.
>
> I have a couple of I/O and a voltage sensor, so I will set it up again
> tomorrow with those in as well.
>
> What do you use /presence for? I have never used it before today.
>
> Mick
>
>
> On 06/08/2020 22:14, Martin Patzak
it does.
> Surely the presence is confirmed by any read of the sensor.
>
> I have just tried setting it to -1, that is invalid, I thought it may
> disable it. I set it to 0 and it is slow every time. I have now set
> it to 999, not sure what the limit would be.
>
> Co
for p in prop_lst:
> print("%s " % p, end="")
> print("")
> for sen in sen_lst:
> print("\n%s " % sen, end="")
> for prop in prop_lst:
> try:
>
ot be anything else running. I just tried running top
>> at the same time, I monitored it at the point of the slow scan and
>> didn't see anything else significant.
>>
>> Mick
>>
>> On 06/08/2020 09:06, Martin Patzak wrote:
>>> It looks like your timi
nding so I can hopefully fine tune my main system.
>
> There should not be anything else running. I just tried running top
> at the same time, I monitored it at the point of the slow scan and
> didn't see anything else significant.
>
> Mick
>
> On 06/08/2020 09:06, Martin Pa
It looks like your timing has improved after all!
in your original Python-code you could time every read for each sensor.
I have also powered sensors and a read is usually faster than 0.1 seconds.
I log in a file if the read took longer than 0.3 seconds, which is
almost never the case.
I also log
/simulataneous
command to 2 seconds, so I must have had issues at the time...
On 05.08.20 09:23, Martin Patzak wrote:
> Hi Mick,
>
> by reading the /uncached value, you are causing a new conversion.
> Read only /latesttemp and it should work fine.
>
> here is my test program, w
Hi Mick,
by reading the /uncached value, you are causing a new conversion.
Read only /latesttemp and it should work fine.
here is my test program, when I first tested simultaneous and pyownet:
> import time
> from pyownet import protocol
>
> op = protocol.proxy("razmaban",port=4304)
> error = 0
with simple read an write operations in
> to files provided at /mnt/1wire and subdirectories.
>
> Regards Heimo
>
> *Gesendet:* Freitag, 13. März 2020 um 18:26 Uhr
> *Von:* "Martin Patzak"
> *An:* "OWFS (One-wire file system) discussion and help"
> ,
Hello Heimo,
after writing to "simultaneous" you have to wait one second.
For Python I would recommend you the library *pyownet *by Stefano Miccoli:
> The official OWFS bindings are
>
> - OW.py, based on SWIG wrapping the C API of libow
> - ownet.py, pure python owserver client
>
> you will fin
Mick,
I made very good experience with https://www.fuchs-shop.com/
All sensors and other one wire components did work at arrival :-)
Martin
On 03.08.19 22:57, Mick Sulley wrote:
> I recently bought 4 DS18B20 sensors from eBay. When I received them
> they did not work, that is they did not show
Hi Mick,
maybe you want to give Stefano's Python-Library for 1wire a try!
https://github.com/miccoli/pyownet
It works excellent ;-)
Cheers,
Martin
On 10.03.19 15:57, Mick Sulley wrote:
> OK I have now reconfigured my system so that all the I/O modules are
> individually powered rather than over
On 10/20/18 7:00 PM, Jan Kandziora wrote:
>
> (I just had the problem with a remote on-off switch. Sometimes, the
> **off** command is broken. Solution: always use anm on-timeout on the
> device. On-commands have to be repeated each few seconds. That way, a
> lost instant-off command will not do
On 05.08.2018 21:20, Colin Law wrote:
> On 5 August 2018 at 20:09, Rowan Sylvester-Bradley
> mailto:ro...@sylvesterbradley.org>> wrote:
>
> If I switch to Raspberry Pi, how do I then connect the OneWire bus
> to the Pi? Can I still use the DS9490R, or do I have to use some
> more hard
> 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 w
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!
ohan
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
écr
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
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)
To: Hans-Frieder Vogt
On 08.08.
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)
To: Eloy Paris
On
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 an
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
r
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&qu
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=
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
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
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
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 versio
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, w
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
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
On 03/03/2017 10:02 AM, Colin Law wrote:
On 3 March 2017 at 08:42, Martin Patzak (GMX) <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
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
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
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
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
>>
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
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:(
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=… op
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_PR
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?
---
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 f
code (e.g. src/rpm)
S.
On 08 Dec 2016, at 16:54, Matthias Urlichs <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
> 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
--
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/
/./
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
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 wi
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
On 12/06/2016 11:53 AM, Jan Kandziora wrote:
Am 06.12.2016 um 09:42 schrieb Martin Patzak (GMX):
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
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
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 mes
On 12/06/2016 11:04 AM, Sven Giermann wrote:
I have no idea of what pyownet does or how it is implemented...
But I know from another project, that DS1820 reports 85.0 deg C when
it encounters errors. Unfortunately without any other error flag!
That's why I implemented a way to accept a temper
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
On 12/05/2016 06:29 PM, Stefano Miccoli wrote:
On 05 Dec 2016, at 18:11, Martin Patzak (GMX) <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
On 12/05/2016 05:42 PM, Stefano Miccoli wrote:
On 05 Dec 2016, at 09:35, Martin Patzak (GMX) <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)://
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
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
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
imultaneous 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:
>
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 wo
On 09/11/2016 06:18 PM, Johan Ström wrote:
> On 10/09/16 14:02, Jan Kandziora wrote:
>> Am 10.09.2016 um 11:22 schrieb Colin Law:
>>> Is there really a need for two? Why
>>> not just have everything in one?
>>>
>> Because of access rights. GitHub only allows full developer access to
>> anything
>
> 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 i
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:
>
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?
ah, very smooth! Thanks a LOT!!!
On 07/20/2016 05:06 PM, Tomasz Torcz wrote:
On Wed, Jul 20, 2016 at 04:52:44PM +0200, Martin Patzak (GMX) wrote:
I wanted to add:
I ask this not because I am too lazy to search, but all I found was this,
which is rather old:
http://owfs.org/index.php?page
documentation of the changes, how do I access this? I cannot find owfs
on git - I must be blind?
Thanks, Martin
On 07/20/2016 03:32 PM, Martin Patzak (GMX) wrote:
Is there an overview over the changes?
I am specifically interested in Johan Ströms improvements for the
LinkUSB Master.
Will this be
Is there an overview over the changes?
I am specifically interested in Johan Ströms improvements for the
LinkUSB Master.
Will this be available as a Debian package before autumn?
Cheers, Martin
On 07/20/2016 02:26 PM, Jan Kandziora wrote:
Am 20.07.2016 um 13:48 schrieb Tomasz Torcz:
Is
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
---
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 wr
On 01/08/2016 06:51 AM, Cornie Malan wrote:
Referring to the following in multi-client environment:
"If I got it right, when owserver returns from the write to
/simultaneous/temperature, fresh temp values can be read from the
cache. If you read from /uncached, you trigger a fresh c
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 excessi
On 01/08/2016 01:07 AM, Stefano Miccoli wrote:
On 07 Jan 2016, at 14:45, Martin Patzak (GMX) <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
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
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)
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 <mailto:lo...@pacific.net>> wrote:
On Sat, 07 Nov 20
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
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
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 d
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
> Po
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 w
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 componen
Thanks Jan,
that is an excellent explanation!
This is the reason why my plain telephone cable works so well for my
network.
Martin
On 11/07/2015 12:33 AM, Jan Kandziora wrote:
Am 06.11.2015 um 23:35 schrieb Colin Law:
What twisted pair does do is to reduce electromagnetic pickup.
Not for
On 11/06/2015 10:25 PM, Loren Amelang wrote:
> ...
>
> It takes a similar 49 mS for owhttpd to respond to the first GET for its web
> page. About 2.2 seconds to GET a temperature sensor, I guess that triggers
> uncached readings of my two sensors.
to prevent updating temperatures while testi
On 11/06/2015 07:33 PM, Jan Kandziora wrote:
Am 06.11.2015 um 16:32 schrieb Martin Patzak (GMX):
Hello All,
owserver version 2.9p8 does not print information set by --error_level
and the use of --foreground or --debug
--debug implies --foreground and --error_level settings, so no need to
1 - 100 of 174 matches
Mail list logo
