Menu
▾
▴
Re: [Owfs-developers] python code printing /statistics
|
From: Mick S. <mi...@su...> - 2020-08-09 09:34:23
|
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 of the docs.......
Mick
On 09/08/2020 10:21, Martin Patzak wrote:
> 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
>>>>
>>
>
|
