headers
Paul Alfille | 1 Jan 2011 16:09
Picon

Re: /settings/timeout/volatile not being honored?

You are using the timeout correctly, but there may be an issue with
whether the timeout is sent to the owserver.

What's your program setup? i.e. are you accessing owserver via owfs or
owhttpd? You may have to set

bus.0/settings/timeout_volatile.

Paul

On Thu, Dec 30, 2010 at 1:53 AM, Eloy Paris <peloy <at> chapus.net> wrote:
> Hello,
>
> I set (dynamically) /settings/timeout/volatile to 300 seconds but doing
> successive "cat /owfs/≤device address>/temperature" (a few seconds
> apart) still causes owserver to go out and fetch a new temperature
> sample (I think this is the case because the cat operation pauses a few
> seconds instead of printing data right away). I would have expected to
> get the same (cached) temperature for the next 300 seconds.
>
> Am I misunderstanding the way /settings/timeout/volatile should work? Is
> there a good way to check that owserver is honoring the volatile timeout
> and that it is not going out to the bus to fetch new data?
>
> I am running 2.8p1 and my bus master is a LinkUSB.
>
> What I want to accomplish by changing /settings/timeout/volatile is to
> prevent a process from blocking while the temperature file is being
> read. Is there a better way than relying on the volatile timeout? I
> thought that caching would help me here.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Eloy Paris | 1 Jan 2011 18:02

Re: /settings/timeout/volatile not being honored?

Hi Paul,

On 01/01/2011 10:09 AM, Paul Alfille wrote:

> You are using the timeout correctly, but there may be an issue with
> whether the timeout is sent to the owserver.
>
> What's your program setup? i.e. are you accessing owserver via owfs or
> owhttpd? You may have to set
>
> bus.0/settings/timeout_volatile.

I access owserver via owfs.

I just checked and bus.0/settings/timeout_volatile is set to the default 
of 15 seconds while settings/timeout_volatile has the 300 seconds I set 
it to. I'll change the former to 300 to see what happens.

What is the difference between bus.0/settings/timeout_volatile and 
settings/timeout_volatile? I mean, which one gets used and under what 
circumstances?

By the way, I no longer need to use a longer volatile timeout since I 
realized I cannot block for a few seconds even every five minutes (I am 
getting temperatures into the MisterHouse home automation program and 
MisterHouse cannot block while the 1-wire bus is read since then other 
home automation activities performed by MisterHouse cannot take place). 
Instead, I am reading owfs 1-wire data from a program that can block, 
and MisterHouse reads, without ever blocking, the data collected by this 
other program.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Alfille | 1 Jan 2011 20:41
Picon

Re: /settings/timeout/volatile not being honored?

On Sat, Jan 1, 2011 at 12:02 PM, Eloy Paris <peloy <at> chapus.net> wrote:
> I just checked and bus.0/settings/timeout_volatile is set to the default
> of 15 seconds while settings/timeout_volatile has the 300 seconds I set
> it to. I'll change the former to 300 to see what happens.
>
> What is the difference between bus.0/settings/timeout_volatile and
> settings/timeout_volatile? I mean, which one gets used and under what
> circumstances?
>

This gets to the heart of where the work is done: in the client or in
the server?

For the ownet clients, it's easy. They don't understand anything about
the query and everything is sent to the server. In fact, you don't
even see that first layer of bus.0

For the traditional clients, like owfs and owhttpd and
ow[perl|python|tcl|php|capi] the program is a little schizophrenic. It
can both connect directly to a bus master, or connect remotely to
owserver. For the most part this is transparent, but caching,
temperature scales and aliases are a little ambiguous.

Caching the values where the live bus master lives seems the only safe
method. Otherwise two clients accessing the same owserver might have
different cached values, and you would save a little on network
communication (usually fast) at the expense of 1-wire communication
(relatively slow).

Temperature scales are kept locally, and the values are scaled only by
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Kusznir | 5 Jan 2011 00:34
Picon

Alarming problems in the DS18B20 (and probably other temps)

Hi all:

I've been reporting for a while that alarming was not working with
DS18B20 temperature chips.  Today we have finally gotten the traces
and compared to the Dallas data sheets to figure out exactly why
they're not working.

Thanks to the relatively new bus traffic debug feature, we were able
to get this.

It appears that all the alarming setup stuff works.  We did find a bug
in the reading of the alarm values: owfs only reads from the
scratchpad; it does NOT first copy from the alarm EEPROM to the
scratchpad.  Therefore, unless you just set the alarm value, the value
OWFS reads out is actually not correct.

After setting Thigh and Tlow, we entered into a loop of echo "1" >
simultaneous/temperature followed by a ls of the alarm directory.  In
our case, the temperature chip always shows up in the alarm directory,
even when it should not.  However, if we cat fasttemp for a chip, it
will disappear from the alarm directory.

Today's research revealed that the issue is that OWFS is NOT handling
the bus powered situation correctly.  It looks like the alarming
function would work perfectly if all of our DS18B20s were externally
powered.  However, we run all of ours parasitic.  I suspect that some
logic needs to be added to OWFS to "know" if it has at least one
bus-powered chip (there's a simple OW command that can be run to do
this, IIRC), and then it would need to execute the strong pullup after
a convert command.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kjetil Torgrim Homme | 6 Jan 2011 16:46
Gravatar

Re: Some of the man pages end with .1so instead of .1 - error or what?

Chris G <cl <at> isbd.net> writes:
> I just want 'man owfsxxx' to work, and it doesn't, even after adding
> the /opt/owfs/share/man directory to the MANPATH database.  The
> trouble is all those wierd xxxx.1so manual pages seem to throw a
> spanner in the works.  Can you point me at anywhere that describes how
> it's supposed to work - then maybe I can mend it and actually read the
> owfs documentation.
>
> Why doesn't it just use ordinary symbolic links?

the .so directive is commonly used on Linux, too:

  linux$ zcat /usr/share/man/man1/help.1.gz
  .so man1/builtins.1

>> .... and why are there manual pages called things like help.1so,
>> that's inevitably going to cause problems.

for the most part, it should work just fine.  after all, you're not
supposed to read these pages directly.  it might work more reliably if,
e.g., man/owfs.1 contained ".so man1/help.1so" rather than
".so help.1so".  also, it would probably be a good idea to use a prefix
for pages only intended for inclusion (like "ow-help.1so"), so that
"man -s 1 help" is certain to bring up the bash builtin, and not the
owfs snippet.

--

-- 
Kjetil T. Homme
Redpill Linpro AS - Changing the game
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Kusznir | 6 Jan 2011 20:20
Picon

Re: Alarming problems in the DS18B20 (and probably other temps)

We did some hacking on the source code.  With a very basic hack to
change the delay on a simultanous temperature command, alarming on
bus-powered 18b20's now work.  I think this hack is not
production-ready, but it does appear to be a fairly easy fix.

--Jim

On Tue, Jan 4, 2011 at 3:34 PM, Jim Kusznir <jkusznir <at> gmail.com> wrote:
> Hi all:
>
> I've been reporting for a while that alarming was not working with
> DS18B20 temperature chips.  Today we have finally gotten the traces
> and compared to the Dallas data sheets to figure out exactly why
> they're not working.
>
> Thanks to the relatively new bus traffic debug feature, we were able
> to get this.
>
> It appears that all the alarming setup stuff works.  We did find a bug
> in the reading of the alarm values: owfs only reads from the
> scratchpad; it does NOT first copy from the alarm EEPROM to the
> scratchpad.  Therefore, unless you just set the alarm value, the value
> OWFS reads out is actually not correct.
>
> After setting Thigh and Tlow, we entered into a loop of echo "1" >
> simultaneous/temperature followed by a ls of the alarm directory.  In
> our case, the temperature chip always shows up in the alarm directory,
> even when it should not.  However, if we cat fasttemp for a chip, it
> will disappear from the alarm directory.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Alfille | 7 Jan 2011 03:50
Picon

Re: Alarming problems in the DS18B20 (and probably other temps)

I see your hack, which will certainly work. The delay was supposed to
be not at the time of "simultaneous", but at the time of the first
temperature read, so work could be done in between.

I'll include your change in the next release. Thank you for your work!

Paul

On Thu, Jan 6, 2011 at 2:20 PM, Jim Kusznir <jkusznir <at> gmail.com> wrote:
> We did some hacking on the source code.  With a very basic hack to
> change the delay on a simultanous temperature command, alarming on
> bus-powered 18b20's now work.  I think this hack is not
> production-ready, but it does appear to be a fairly easy fix.
>
> --Jim
>
> On Tue, Jan 4, 2011 at 3:34 PM, Jim Kusznir <jkusznir <at> gmail.com> wrote:
>> Hi all:
>>
>> I've been reporting for a while that alarming was not working with
>> DS18B20 temperature chips.  Today we have finally gotten the traces
>> and compared to the Dallas data sheets to figure out exactly why
>> they're not working.
>>
>> Thanks to the relatively new bus traffic debug feature, we were able
>> to get this.
>>
>> It appears that all the alarming setup stuff works.  We did find a bug
>> in the reading of the alarm values: owfs only reads from the
>> scratchpad; it does NOT first copy from the alarm EEPROM to the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Alfille | 7 Jan 2011 04:53
Picon

New release OWFS 2.8p5

Release note for OWFS 2.8p5

1. Fixes from Jim Kaszmir for DS18x20 temperature alarms and simultaneous reads
2. Fixes based on test environment from Achim Hennies for LinkHubE
   -- Proper telnet parsing, baud rate, and even Xport control port
reset if needed
3, Improvements in timeouts, dropped connections, and reconnections
for all serial and network interfaces.
4. Start of implementation based on Roberto Spadim's recommendation
that we support
   telnet serial connection RFC2217
   Use ser2net as the device:
   e.g. sudo ser2net -C "3333:telnet:0:/dev/ttyUSB0:9600 1STOPBIT
8DATABITS remctl"
5. Add some bit-level commends for future BAE function and some Dallas
security chip support
6. Fix remote BAE over owserver problem.

Link:
https://sourceforge.net/projects/owfs/

------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl
Permalink | Reply | 7 comments |
headers
Jim Kusznir | 7 Jan 2011 18:37
Picon

Re: New release OWFS 2.8p5

This version seems to have introduced a new bug:  one cannot write
into uncached/simultaneous/temperature (It returns a bash error,
although it is there).  All other operations we've tested work fine
(we can individually read temperatures, we can set the alarming
values, etc.).  The same command works by stopping p5 and starting our
modified p4.

--Jim

On Thu, Jan 6, 2011 at 7:53 PM, Paul Alfille <paul.alfille <at> gmail.com> wrote:
> Release note for OWFS 2.8p5
>
> 1. Fixes from Jim Kaszmir for DS18x20 temperature alarms and simultaneous reads
> 2. Fixes based on test environment from Achim Hennies for LinkHubE
>   -- Proper telnet parsing, baud rate, and even Xport control port
> reset if needed
> 3, Improvements in timeouts, dropped connections, and reconnections
> for all serial and network interfaces.
> 4. Start of implementation based on Roberto Spadim's recommendation
> that we support
>   telnet serial connection RFC2217
>   Use ser2net as the device:
>   e.g. sudo ser2net -C "3333:telnet:0:/dev/ttyUSB0:9600 1STOPBIT
> 8DATABITS remctl"
> 5. Add some bit-level commends for future BAE function and some Dallas
> security chip support
> 6. Fix remote BAE over owserver problem.
>
> Link:
> https://sourceforge.net/projects/owfs/
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jim Kusznir | 7 Jan 2011 18:53
Picon

Re: New release OWFS 2.8p5

To follow up, the errors we're seeing may be tied to our specific bus
master (the Dallas blue USB master).  When we turn debugging way up,
we get a "no bus master found".  We also found if we write "f" to the
temperature scale, we get the same message and our terminal that wrote
that hangs.

--Jim

On Fri, Jan 7, 2011 at 9:37 AM, Jim Kusznir <jkusznir <at> gmail.com> wrote:
> This version seems to have introduced a new bug:  one cannot write
> into uncached/simultaneous/temperature (It returns a bash error,
> although it is there).  All other operations we've tested work fine
> (we can individually read temperatures, we can set the alarming
> values, etc.).  The same command works by stopping p5 and starting our
> modified p4.
>
> --Jim
>
> On Thu, Jan 6, 2011 at 7:53 PM, Paul Alfille <paul.alfille <at> gmail.com> wrote:
>> Release note for OWFS 2.8p5
>>
>> 1. Fixes from Jim Kaszmir for DS18x20 temperature alarms and simultaneous reads
>> 2. Fixes based on test environment from Achim Hennies for LinkHubE
>>   -- Proper telnet parsing, baud rate, and even Xport control port
>> reset if needed
>> 3, Improvements in timeouts, dropped connections, and reconnections
>> for all serial and network interfaces.
>> 4. Start of implementation based on Roberto Spadim's recommendation
>> that we support
>>   telnet serial connection RFC2217
(Continue reading)

Permalink | Reply | 0 comments |

Gmane