Am 11.10.2015 um 08:34 schrieb Loren Amelang:
>
> I see now that is created by w1, independent of OWFS!
>
YES. Most modern Linux distributions have a "sysfs" mounted at /sys.
This pseudo-filesystem exports various static and dynamic information
and settings of the kernel and kernel drivers to userspace.
>
>>> The "-62" errors always look like that - one line of all "ff"
>>> with a bad CRC, followed by the correct bits with a bad
>>> temperature.
>
>> These are from linux/drivers/w1/slaves/w1_therm.c, around line
>> 250.
>>
>> These CRC errors aren't reported to owfs. The reading is just
>> ignored and the old value sticks in the chip structure the w1
>> driver manages. So OWFS isn't aware there was an error at all.
>
> So I want to be querying owserver instead of w1?
>
You most likely want to decide whether you want to use the owfs tools at
all or just want to query the w1 kernel driver directly.
With the owfs tools, you get network transparency, a wider range of
supported host adapters and slave devices and the cache. If you don't
need any of that, you gain nothing but complexity.
>
> So are you saying owshell might be able to read and write config
> values that the owhttpd can't?
>
Most unlikely, but just try it. As said, owhttpd is just an interface to
owserver in your setup. The owshell tools do nothing different. Maybe
your owhttpd is started with the -r or --readonly option for security
reasons? Check it with
$ ps aux | grep owhttpd
> Maybe pyownet could do the same? I
> just installed it and got it to read temperatures - and if it is
> read again quickly, it returns results instantly. I guess it is
> interacting with the 15 second owserver timeout. Sometimes I can
> wait almost 15 seconds and still get an instant response, but other
> times it pauses to read again less than five seconds from the last
> read.
>
when you read the cached value, the cache timeout is *not* reset. That
means, if you happen to read the node three seconds before the cache for
it expires, and read it again five seconds later, owserver will have to
sample the temperature value again from the chip.
>
> So getting back to the original issues...
>
[...]
>
> Sounds like maybe one could turn off the searches to eliminate the
> "all ff, -62" errors. I wonder if some glitch would then lose the
> sensors and without search active they wouldn't come back.
>
No, they won't go away then. The sensor list is only updated during search.
>
> But something isn't right about that explanation. I watched
> w1_master_attempts, and it is clearly counting the 10-second reads,
> not the much rarer bus reset and "all ff, -62" errors: ---
>
This error will only happens if the search thread is doing the bus reset
during temperature conversion, because the other thread isn't aware it
can't read back the temperature after conversion before doing another
"Match ROM" command on that slave (it doesn't).
But yes, disabling the w1 search thread would eliminate that error.
>
> They say: "w1_master_timeout - the delay in seconds between
> searches" and mine is clearly 10, so that doesn't seem to define the
> rare ~4 mS bus resets.
>
You got it wrong. These aren't bus resets. Bus resets happen all the
time, they are part of the protocol, the equivalent of "HEY SLAVES,
LISTEN!" and then the master issues one of the "ROM commands" to select
one or more slaves. A bus reset is a low of 480µs, not longer.
All lows of 960µs and longer are sure power-down-conditions.
>
> And none of this has let me understand how changing the pullup value
> can change the temperatures!
>
As the values CRAWL I expect it to be additonal heat either delivered to
the sensor through the wires or generated inside the sensor because of
some short-circuit condition.
Kind regards
Jan
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
