here is some documentation about the values in /statistics:
http://owfs.sourceforge.net/statistics.html
I do not know if there is more about that within the owfs project...
there should be more at Maxim's website about the interface protocol
which owfs is based upon.
On 08.08.20 19:07, Mick
quick question: do you have the 0.7 delay on EVERY module after the
/presence time elapsed?
It is strange that I do not experience that.
No, the CRC16_errors and CRC16_tries should not increase every loop
CRC errors and tries are part of the Dallas (now Maxim) 1wire specification.
It ensures
Thanks for that, I just ran your code on my test system -
pi@pi4B:~/v12_5 $ python3 read_stats.py
temp is 24.625
success 934310
tries.0 470429
tries.1 0
tries.2 0
CRC16_tries 11768
CRC16_errors 11768
pi@pi4B:~/v12_5 $
Time to do some reading
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,
Things I would try, in random order.
- Try an ‘owdir /uncached ’ command before writing to simultaneous, just to
refresh the owserver view of the devices on the bus. Maybe a single owdir
command is faster that querying the sensors one at a time.
- Do not use owserver aliases, use only bus
correction:
An operation will be tried three times, first try and two re-tries -
re-tries result in an increased operation time - which will be logged in
/statistics/*read*/tries.x - where 0 is the first try or
/statistics/*write*/tries.x respectively
hence /tries.0 will be always greater than
here is a quick python code to read some /statistics
and yes, the owserver has been running for a looong time :-D
> from pyownet import protocol
> import time
>
> op = protocol.proxy()
>
> try:
> #x = op.read('/uncached/29.1CBF0E00/sensed.ALL')
> #print 'sensed is',x
> x =
