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.1CBF0E000000/sensed.ALL')
>     #print 'sensed is',x
>     x = op.read('/uncached/28.CFB920060000/latesttemp')
>     print 'temp is',x
>
>     x = op.read('/statistics/read/success')
>     print 'success',x
>
>     x = op.read('/statistics/read/tries.0')
>     print 'tries.0',x
>
>     x = op.read('/statistics/read/tries.1')
>     print 'tries.1',x
>
>     x = op.read('/statistics/read/tries.2')
>     print 'tries.2',x
>
>     x = op.read('/statistics/errors/CRC16_tries')
>     print 'CRC16_tries',x
>
>     x = op.read('/statistics/errors/CRC16_errors')
>     print 'CRC16_errors',x
>
>
> except Exception as e:
>     print str(e)
>
>

temp is      57.9375
success    219962160        (why is success 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_errors         1351        (some CRC16 errors were cause by
writes, hence the discrepancy)




On 09.08.20 10:52, Martin Patzak wrote:
> 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 Sulley wrote:
>>
>> I have just run it again, sleep for 3 seconds after the
>> simultaneous/temperature write and sleep 25 seconds at the end of the
>> loop.  Presence is at 120 and I see a delay every 130 seconds or so. 
>> The delay is on reading whichever parameter is first, so if I read
>> present first then that is the 0.7 scan, the other parameters are <
>> 0.1, but If I read type first then that is 0.7 sec, etc
>>
>> I am also reading CR16_errors and CR16_tries, these are the same and
>> both increase by 8 each loop.  Is that normal?  Is there any
>> 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 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 can have a look in /statistics for retries and errors
>>>
>>> On 08.08.20 01:04, Mick Sulley wrote:
>>>> Update on test findings.  Test setup was 19 - DS18B20 temperature,
>>>> 2 - DS2413 IO and 1 - DS2437 Voltage, Raspberry Pi4 with Sheepwalk
>>>> RPi3 Adapter
>>>>
>>>> 1) /simultaneous/temperature does work, best to read latesttemp.
>>>>
>>>> 2) /settings/timeout/presence cannot be set or read via the owhttpd
>>>> web page, you must use owwrite & owread
>>>>
>>>> 3) Reading values (after setting simultaneous) normally takes < 0.1
>>>> seconds
>>>>
>>>> 4) After the /settings/timeout/presence interval the next read for
>>>> every device will take around 0.7 seconds.  Note if you read
>>>> multiple fields it is only the first one which takes the increased
>>>> time.
>>>>
>>>> 5) The increased time after /settings/timeout/presence interval
>>>> applies to all devices, not just temperature
>>>>
>>>>
>>>> Mick
>>>
>

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

Reply via email to