owfs-developers — Developer's list for OWFS

Re: [Owfs-developers] python code printing /statistics

[Martin P. <Mar...@GM...>]

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
>>>
>

Re: [Owfs-developers] Simultaneous - Update

[Martin P. <Mar...@GM...>]

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 the re-tries that occur in
case of a CRC16 error /tries.1 and /tries.2


On 09.08.20 10:49, Martin Patzak wrote:
> An operation will be retried three times - resulting in an increased
> operation time - which will be logged in /statistics/*read*/tries.x -
> where 0 is the first re-try or /statistics/*write*/tries.x respectively
> hence /tries.0 will be always greater than /tries.1 and /tries.2

Re: [Owfs-developers] owserver /statistics

[Martin P. <Mar...@GM...>]

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
>>

Re: [Owfs-developers] Simultaneous - Update

[Martin P. <Mar...@GM...>]

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 data integrity.
Here is the page on Maxim's website:

https://www.maximintegrated.com/en/design/technical-documents/app-notes/2/27.html

The way I understood it years ago when I was tinkering with it- and I
hope I remember right -, was:

If a low level 16 bit read (e.g. reading a temperature) - or write -
fails because the data on the bus is not correct, then the CRC16 error
gets increased by 1, and the operation gets retried.
An operation will be retried three times - resulting in an increased
operation time - which will be logged in /statistics/*read*/tries.x -
where 0 is the first re-try or /statistics/*write*/tries.x respectively
hence /tries.0 will be always greater than /tries.1 and /tries.2

 
you could read /statistics/CRC16_errors after every read or write and
print when the value increases to find out which module gives you the errors


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
>>

Re: [Owfs-developers] Simultaneous - Update

[Mick S. <mi...@su...>]

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
>

Re: [Owfs-developers] Simultaneous - Update

[Martin P. <Mar...@GM...>]

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

Re: [Owfs-developers] Simultaneous - Update

[Mick S. <mi...@su...>]

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

Re: [Owfs-developers] Simultaneous not working

[Stefano M. <mo...@ic...>]

> On 6 Aug 2020, at 21:42, Mick Sulley <mi...@su...> wrote:
> 
> I did change to persistent and I didn't see a difference.
> 
> 

Just a quick background. The persistent=True option is useful to shave a few milliseconds from each owserver query by not having to create and pull down a TCP socket and for limiting the number of sockets in the TIME_WAIT status, which usually is not a problem, but could be problematic for machines with limited memory. You can check the sockets in TIME_WAIT with the shell command 

ss -a '( dport 4304 or sport 4304 )'

> /settings/timeout/presence is what is causing it.  I had tried changing it yesterday, via the httpd web page, but this time I checked it with owread and that showed it still at 120, so I changed it to 20 with owwrite re-ran my Python script and yes it slows every 20 seconds
> 
> What is the purpose of /settings/timeout/presence?  The man page says 'Seconds until the presence and bus location of a 1-wire device expires in the cache.', but I don't really understand what it does.  Surely the presence is confirmed by any read of the sensor.   
> 

There is a message in the owserver protocol to check the presence of a sensor 

shell: owpresent XXX 
pyownet: owproxy.present(“XXX”)

I rarely use it but I assume that the reply to this query is cached, with a timeout of /settings/timeout/presence …
> I have just tried setting it to -1, that is invalid, I thought it may disable it.  I set it to 0 and it is slow every time.  I have now set it to 9999999, not sure what the limit would be.
> 
> Comments?
> 
> Mick
> 
> On 06/08/2020 16:48, Martin Patzak wrote:
>> looks like you are getting close :-)
>> 
>> I checked, and the only timeout of owserver that matches 120 is /settings/timeout/presence
>> 
>> 
>> 
>> On 06.08.20 16:21, Mick Sulley wrote:
>>> Well this gets more curious.  I am now measuring the time for each read, reading type, power and latesttemp.  Time for all is generally < 0.1 seconds, but then when I hit the slow loop the read for type is around 0.7 seconds, the others still < 0.1 seconds.  I don't really need type so I removed it and re-tested, on slow loops the power read is around 0.7 seconds, latesttemp still < 0.1 seconds.  So I removed power as well, just reading latesttemp, on slow loops that is now around 0.7 seconds.  So it seems that at some point a sensor takes many times longer for its next read, irrespective of which field is read.
>>> 
>>> I have now tested with 19, 11 and 2 sensors and the slow loop occurs every 120 seconds.  I am intrigued to know what causes this, any ideas?
>>> 
>>> Thanks
>>> 
>>> Mick
>>> 
>>> On 06/08/2020 10:23, Mick Sulley wrote:
>>>> OK I will log read times and see what that shows.
>>>> 
>>>> You say 'I also log if the error of the 1wire bus changes.' how do you do that?
>>>> 
>>>> No I don't really need to read that fast, this is just a test setup to get a better understanding so I can hopefully fine tune my main system.
>>>> 
>>>> There should not be anything else running.  I just tried running top at the same time, I monitored it at the point of the slow scan and didn't see anything else significant.
>>>> 
>>>> Mick
>>>> 
>>>> On 06/08/2020 09:06, Martin Patzak wrote:
>>>>> It looks like your timing has improved after all!
>>>>> 
>>>>> in your original Python-code you could time every read for each sensor.
>>>>> I have also powered sensors and a read is usually faster than 0.1 seconds.
>>>>> I log in a file if the read took longer than 0.3 seconds, which is almost never the case.
>>>>> I also log in the file if the whole reading loop took longer than 3 seconds, which again is almost never the case.
>>>>> 
>>>>> I also log if the error of the 1wire bus changes.
>>>>> 
>>>>> I read 25 sensors every full and every half minute, so maybe you could implement a delay as well and see if things get more consistent.
>>>>> Do you need to read so fast in a loop for you application?
>>>>> 
>>>>> What else is running on your machine? You could run top in parallel to your python loop.
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Owfs-developers mailing list
>>>> Owf...@li... <mailto:Owf...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers <https://lists.sourceforge.net/lists/listinfo/owfs-developers>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Owfs-developers mailing list
>>> Owf...@li... <mailto:Owf...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers <https://lists.sourceforge.net/lists/listinfo/owfs-developers>
>> 
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

[Martin P. <Mar...@GM...>]

hmm 300 seconds. Strange...

I use /presence only in case a read or write fails (which is very
rarely) - I then check /presence before re-reading or re-writing of that
module.
In my first 1 wire net routing I was going along existing paths with
power-cables and I had modules disappearing and CRC16 errors more
frequently.

By having an eye on errors and retries, you can see how robust your
network is and get early warning if individual sensors / modules might
have a problem

On 06.08.20 23:58, Mick Sulley wrote:
>
> No, just tested again and it now delays every 300 seconds.  Not the
> faintest idea why that should be.
>
> I have a couple of I/O and a voltage sensor, so I will set it up again
> tomorrow with those in as well.
>
> What do you use /presence for?  I have never used it before today.
>
> Mick
>
>
> On 06/08/2020 22:14, Martin Patzak wrote:
>> I read the 25 powered sensors every 30 seconds and I don't experience
>> a delay every 120 seconds (my /presence is at default 120)
>>
>> I use /presence only when I get an error reading a sensor (happens
>> very rarely, but it happens)
>> Then I wait until the sensor is present again before reading it. I
>> use the previous value instead.
>>
>> I also read 2 IO modules every second. Those are not affected by a
>> delay every 120 seconds either.
>>
>> Let's wait and hear what others say to that attribute.
>>
>> If you set it to 9999999 you experience no delays anymore?
>>
>> On 06.08.20 21:42, Mick Sulley wrote:
>>>
>>> I did change to persistent and I didn't see a difference.
>>>
>>> //settings/timeout/presence /is what is causing it.  I had tried
>>> changing it yesterday, via the httpd web page, but this time I
>>> checked it with owread and that showed it still at 120, so I changed
>>> it to 20 with owwrite re-ran my Python script and yes it slows every
>>> 20 seconds
>>>
>>> What is the purpose of //settings/timeout/presence/?  The man page
>>> says 'Seconds until the /presence/ and bus location of a 1-wire
>>> device expires in the cache.', but I don't really understand what it
>>> does.  Surely the presence is confirmed by any read of the sensor.  
>>>
>>> I have just tried setting it to -1, that is invalid, I thought it
>>> may disable it.  I set it to 0 and it is slow every time.  I have
>>> now set it to 9999999, not sure what the limit would be.
>>>
>>> Comments?
>>>
>>> Mick
>>>
>>> On 06/08/2020 16:48, Martin Patzak wrote:
>>>> looks like you are getting close :-)
>>>>
>>>> I checked, and the only timeout of owserver that matches 120 is
>>>> //settings/timeout/presence
>>>>
>>>>
>>>> /
>>>> On 06.08.20 16:21, Mick Sulley wrote:
>>>>>
>>>>> Well this gets more curious.  I am now measuring the time for each
>>>>> read, reading type, power and latesttemp.  Time for all is
>>>>> generally < 0.1 seconds, but then when I hit the slow loop the
>>>>> read for type is around 0.7 seconds, the others still < 0.1
>>>>> seconds.  I don't really need type so I removed it and re-tested,
>>>>> on slow loops the power read is around 0.7 seconds, latesttemp
>>>>> still < 0.1 seconds.  So I removed power as well, just reading
>>>>> latesttemp, on slow loops that is now around 0.7 seconds.  So it
>>>>> seems that at some point a sensor takes many times longer for its
>>>>> next read, irrespective of which field is read.
>>>>>
>>>>> I have now tested with 19, 11 and 2 sensors and the slow loop
>>>>> occurs every 120 seconds.  I am intrigued to know what causes
>>>>> this, any ideas?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Mick
>>>>>
>>>>> On 06/08/2020 10:23, Mick Sulley wrote:
>>>>>>
>>>>>> OK I will log read times and see what that shows.
>>>>>>
>>>>>> You say 'I also log if the error of the 1wire bus changes.' how
>>>>>> do you do that?
>>>>>>
>>>>>> No I don't really need to read that fast, this is just a test
>>>>>> setup to get a better understanding so I can hopefully fine tune
>>>>>> my main system.
>>>>>>
>>>>>> There should not be anything else running.  I just tried running
>>>>>> top at the same time, I monitored it at the point of the slow
>>>>>> scan and didn't see anything else significant.
>>>>>>
>>>>>> Mick
>>>>>>
>>>>>> On 06/08/2020 09:06, Martin Patzak wrote:
>>>>>>> It looks like your timing has improved after all!
>>>>>>>
>>>>>>> in your original Python-code you could time every read for each
>>>>>>> sensor.
>>>>>>> I have also powered sensors and a read is usually faster than
>>>>>>> 0.1 seconds.
>>>>>>> I log in a file if the read took longer than 0.3 seconds, which
>>>>>>> is almost never the case.
>>>>>>> I also log in the file if the whole reading loop took longer
>>>>>>> than 3 seconds, which again is almost never the case.
>>>>>>>
>>>>>>> I also log if the error of the 1wire bus changes.
>>>>>>>
>>>>>>> I read 25 sensors every full and every half minute, so maybe you
>>>>>>> could implement a delay as well and see if things get more
>>>>>>> consistent.
>>>>>>> Do you need to read so fast in a loop for you application?
>>>>>>>
>>>>>>> What else is running on your machine? You could run top in
>>>>>>> parallel to your python loop.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Owfs-developers mailing list
>>>>>> Owf...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Owfs-developers mailing list
>>>>> Owf...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>>>
>>

Re: [Owfs-developers] Simultaneous not working

[Mick S. <mi...@su...>]

No, just tested again and it now delays every 300 seconds.  Not the 
faintest idea why that should be.

I have a couple of I/O and a voltage sensor, so I will set it up again 
tomorrow with those in as well.

What do you use /presence for?  I have never used it before today.

Mick


On 06/08/2020 22:14, Martin Patzak wrote:
> I read the 25 powered sensors every 30 seconds and I don't experience 
> a delay every 120 seconds (my /presence is at default 120)
>
> I use /presence only when I get an error reading a sensor (happens 
> very rarely, but it happens)
> Then I wait until the sensor is present again before reading it. I use 
> the previous value instead.
>
> I also read 2 IO modules every second. Those are not affected by a 
> delay every 120 seconds either.
>
> Let's wait and hear what others say to that attribute.
>
> If you set it to 9999999 you experience no delays anymore?
>
> On 06.08.20 21:42, Mick Sulley wrote:
>>
>> I did change to persistent and I didn't see a difference.
>>
>> //settings/timeout/presence /is what is causing it.  I had tried 
>> changing it yesterday, via the httpd web page, but this time I 
>> checked it with owread and that showed it still at 120, so I changed 
>> it to 20 with owwrite re-ran my Python script and yes it slows every 
>> 20 seconds
>>
>> What is the purpose of //settings/timeout/presence/? The man page 
>> says 'Seconds until the /presence/ and bus location of a 1-wire 
>> device expires in the cache.', but I don't really understand what it 
>> does.  Surely the presence is confirmed by any read of the sensor.
>>
>> I have just tried setting it to -1, that is invalid, I thought it may 
>> disable it.  I set it to 0 and it is slow every time.  I have now set 
>> it to 9999999, not sure what the limit would be.
>>
>> Comments?
>>
>> Mick
>>
>> On 06/08/2020 16:48, Martin Patzak wrote:
>>> looks like you are getting close :-)
>>>
>>> I checked, and the only timeout of owserver that matches 120 is 
>>> //settings/timeout/presence
>>>
>>>
>>> /
>>> On 06.08.20 16:21, Mick Sulley wrote:
>>>>
>>>> Well this gets more curious.  I am now measuring the time for each 
>>>> read, reading type, power and latesttemp.  Time for all is 
>>>> generally < 0.1 seconds, but then when I hit the slow loop the read 
>>>> for type is around 0.7 seconds, the others still < 0.1 seconds.  I 
>>>> don't really need type so I removed it and re-tested, on slow loops 
>>>> the power read is around 0.7 seconds, latesttemp still < 0.1 
>>>> seconds.  So I removed power as well, just reading latesttemp, on 
>>>> slow loops that is now around 0.7 seconds. So it seems that at some 
>>>> point a sensor takes many times longer for its next read, 
>>>> irrespective of which field is read.
>>>>
>>>> I have now tested with 19, 11 and 2 sensors and the slow loop 
>>>> occurs every 120 seconds.  I am intrigued to know what causes this, 
>>>> any ideas?
>>>>
>>>> Thanks
>>>>
>>>> Mick
>>>>
>>>> On 06/08/2020 10:23, Mick Sulley wrote:
>>>>>
>>>>> OK I will log read times and see what that shows.
>>>>>
>>>>> You say 'I also log if the error of the 1wire bus changes.' how do 
>>>>> you do that?
>>>>>
>>>>> No I don't really need to read that fast, this is just a test 
>>>>> setup to get a better understanding so I can hopefully fine tune 
>>>>> my main system.
>>>>>
>>>>> There should not be anything else running.  I just tried running 
>>>>> top at the same time, I monitored it at the point of the slow scan 
>>>>> and didn't see anything else significant.
>>>>>
>>>>> Mick
>>>>>
>>>>> On 06/08/2020 09:06, Martin Patzak wrote:
>>>>>> It looks like your timing has improved after all!
>>>>>>
>>>>>> in your original Python-code you could time every read for each 
>>>>>> sensor.
>>>>>> I have also powered sensors and a read is usually faster than 0.1 
>>>>>> seconds.
>>>>>> I log in a file if the read took longer than 0.3 seconds, which 
>>>>>> is almost never the case.
>>>>>> I also log in the file if the whole reading loop took longer than 
>>>>>> 3 seconds, which again is almost never the case.
>>>>>>
>>>>>> I also log if the error of the 1wire bus changes.
>>>>>>
>>>>>> I read 25 sensors every full and every half minute, so maybe you 
>>>>>> could implement a delay as well and see if things get more 
>>>>>> consistent.
>>>>>> Do you need to read so fast in a loop for you application?
>>>>>>
>>>>>> What else is running on your machine? You could run top in 
>>>>>> parallel to your python loop.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Owfs-developers mailing list
>>>>> Owf...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>>>
>>>>
>>>> _______________________________________________
>>>> Owfs-developers mailing list
>>>> Owf...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>>
>

Re: [Owfs-developers] Simultaneous not working

[Martin P. <Mar...@GM...>]

I read the 25 powered sensors every 30 seconds and I don't experience a
delay every 120 seconds (my /presence is at default 120)

I use /presence only when I get an error reading a sensor (happens very
rarely, but it happens)
Then I wait until the sensor is present again before reading it. I use
the previous value instead.

I also read 2 IO modules every second. Those are not affected by a delay
every 120 seconds either.

Let's wait and hear what others say to that attribute.

If you set it to 9999999 you experience no delays anymore?

On 06.08.20 21:42, Mick Sulley wrote:
>
> I did change to persistent and I didn't see a difference.
>
> //settings/timeout/presence /is what is causing it.  I had tried
> changing it yesterday, via the httpd web page, but this time I checked
> it with owread and that showed it still at 120, so I changed it to 20
> with owwrite re-ran my Python script and yes it slows every 20 seconds
>
> What is the purpose of //settings/timeout/presence/?  The man page
> says 'Seconds until the /presence/ and bus location of a 1-wire device
> expires in the cache.', but I don't really understand what it does. 
> Surely the presence is confirmed by any read of the sensor.  
>
> I have just tried setting it to -1, that is invalid, I thought it may
> disable it.  I set it to 0 and it is slow every time.  I have now set
> it to 9999999, not sure what the limit would be.
>
> Comments?
>
> Mick
>
> On 06/08/2020 16:48, Martin Patzak wrote:
>> looks like you are getting close :-)
>>
>> I checked, and the only timeout of owserver that matches 120 is
>> //settings/timeout/presence
>>
>>
>> /
>> On 06.08.20 16:21, Mick Sulley wrote:
>>>
>>> Well this gets more curious.  I am now measuring the time for each
>>> read, reading type, power and latesttemp.  Time for all is generally
>>> < 0.1 seconds, but then when I hit the slow loop the read for type
>>> is around 0.7 seconds, the others still < 0.1 seconds.  I don't
>>> really need type so I removed it and re-tested, on slow loops the
>>> power read is around 0.7 seconds, latesttemp still < 0.1 seconds. 
>>> So I removed power as well, just reading latesttemp, on slow loops
>>> that is now around 0.7 seconds.  So it seems that at some point a
>>> sensor takes many times longer for its next read, irrespective of
>>> which field is read.
>>>
>>> I have now tested with 19, 11 and 2 sensors and the slow loop occurs
>>> every 120 seconds.  I am intrigued to know what causes this, any ideas?
>>>
>>> Thanks
>>>
>>> Mick
>>>
>>> On 06/08/2020 10:23, Mick Sulley wrote:
>>>>
>>>> OK I will log read times and see what that shows.
>>>>
>>>> You say 'I also log if the error of the 1wire bus changes.' how do
>>>> you do that?
>>>>
>>>> No I don't really need to read that fast, this is just a test setup
>>>> to get a better understanding so I can hopefully fine tune my main
>>>> system.
>>>>
>>>> There should not be anything else running.  I just tried running
>>>> top at the same time, I monitored it at the point of the slow scan
>>>> and didn't see anything else significant.
>>>>
>>>> Mick
>>>>
>>>> On 06/08/2020 09:06, Martin Patzak wrote:
>>>>> It looks like your timing has improved after all!
>>>>>
>>>>> in your original Python-code you could time every read for each
>>>>> sensor.
>>>>> I have also powered sensors and a read is usually faster than 0.1
>>>>> seconds.
>>>>> I log in a file if the read took longer than 0.3 seconds, which is
>>>>> almost never the case.
>>>>> I also log in the file if the whole reading loop took longer than
>>>>> 3 seconds, which again is almost never the case.
>>>>>
>>>>> I also log if the error of the 1wire bus changes.
>>>>>
>>>>> I read 25 sensors every full and every half minute, so maybe you
>>>>> could implement a delay as well and see if things get more consistent.
>>>>> Do you need to read so fast in a loop for you application?
>>>>>
>>>>> What else is running on your machine? You could run top in
>>>>> parallel to your python loop.
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Owfs-developers mailing list
>>>> Owf...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>>
>>>
>>> _______________________________________________
>>> Owfs-developers mailing list
>>> Owf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>

Re: [Owfs-developers] Simultaneous not working

[Mick S. <mi...@su...>]

I did change to persistent and I didn't see a difference.

//settings/timeout/presence /is what is causing it.  I had tried 
changing it yesterday, via the httpd web page, but this time I checked 
it with owread and that showed it still at 120, so I changed it to 20 
with owwrite re-ran my Python script and yes it slows every 20 seconds

What is the purpose of //settings/timeout/presence/?  The man page says 
'Seconds until the /presence/ and bus location of a 1-wire device 
expires in the cache.', but I don't really understand what it does.  
Surely the presence is confirmed by any read of the sensor.

I have just tried setting it to -1, that is invalid, I thought it may 
disable it.  I set it to 0 and it is slow every time.  I have now set it 
to 9999999, not sure what the limit would be.

Comments?

Mick
//

On 06/08/2020 16:48, Martin Patzak wrote:
> looks like you are getting close :-)
>
> I checked, and the only timeout of owserver that matches 120 is 
> //settings/timeout/presence
>
>
> /
> On 06.08.20 16:21, Mick Sulley wrote:
>>
>> Well this gets more curious.  I am now measuring the time for each 
>> read, reading type, power and latesttemp.  Time for all is generally 
>> < 0.1 seconds, but then when I hit the slow loop the read for type is 
>> around 0.7 seconds, the others still < 0.1 seconds.  I don't really 
>> need type so I removed it and re-tested, on slow loops the power read 
>> is around 0.7 seconds, latesttemp still < 0.1 seconds.  So I removed 
>> power as well, just reading latesttemp, on slow loops that is now 
>> around 0.7 seconds.  So it seems that at some point a sensor takes 
>> many times longer for its next read, irrespective of which field is read.
>>
>> I have now tested with 19, 11 and 2 sensors and the slow loop occurs 
>> every 120 seconds.  I am intrigued to know what causes this, any ideas?
>>
>> Thanks
>>
>> Mick
>>
>> On 06/08/2020 10:23, Mick Sulley wrote:
>>>
>>> OK I will log read times and see what that shows.
>>>
>>> You say 'I also log if the error of the 1wire bus changes.' how do 
>>> you do that?
>>>
>>> No I don't really need to read that fast, this is just a test setup 
>>> to get a better understanding so I can hopefully fine tune my main 
>>> system.
>>>
>>> There should not be anything else running.  I just tried running top 
>>> at the same time, I monitored it at the point of the slow scan and 
>>> didn't see anything else significant.
>>>
>>> Mick
>>>
>>> On 06/08/2020 09:06, Martin Patzak wrote:
>>>> It looks like your timing has improved after all!
>>>>
>>>> in your original Python-code you could time every read for each sensor.
>>>> I have also powered sensors and a read is usually faster than 0.1 
>>>> seconds.
>>>> I log in a file if the read took longer than 0.3 seconds, which is 
>>>> almost never the case.
>>>> I also log in the file if the whole reading loop took longer than 3 
>>>> seconds, which again is almost never the case.
>>>>
>>>> I also log if the error of the 1wire bus changes.
>>>>
>>>> I read 25 sensors every full and every half minute, so maybe you 
>>>> could implement a delay as well and see if things get more consistent.
>>>> Do you need to read so fast in a loop for you application?
>>>>
>>>> What else is running on your machine? You could run top in parallel 
>>>> to your python loop.
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Owfs-developers mailing list
>>> Owf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>>
>> _______________________________________________
>> Owfs-developers mailing list
>> Owf...@li...
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

Re: [Owfs-developers] Simultaneous not working

[Stefano M. <mo...@ic...>]

Did you check if persistent=True makes any difference?

> On 6 Aug 2020, at 16:21, Mick Sulley <mi...@su...> wrote:
> 
> Well this gets more curious.  I am now measuring the time for each read, reading type, power and latesttemp.  Time for all is generally < 0.1 seconds, but then when I hit the slow loop the read for type is around 0.7 seconds, the others still < 0.1 seconds.  I don't really need type so I removed it and re-tested, on slow loops the power read is around 0.7 seconds, latesttemp still < 0.1 seconds.  So I removed power as well, just reading latesttemp, on slow loops that is now around 0.7 seconds.  So it seems that at some point a sensor takes many times longer for its next read, irrespective of which field is read.
> 
> I have now tested with 19, 11 and 2 sensors and the slow loop occurs every 120 seconds.  I am intrigued to know what causes this, any ideas?
> 
> Thanks
> 
> Mick
> 
> On 06/08/2020 10:23, Mick Sulley wrote:
>> OK I will log read times and see what that shows.
>> 
>> You say 'I also log if the error of the 1wire bus changes.' how do you do that?
>> 
>> No I don't really need to read that fast, this is just a test setup to get a better understanding so I can hopefully fine tune my main system.
>> 
>> There should not be anything else running.  I just tried running top at the same time, I monitored it at the point of the slow scan and didn't see anything else significant.
>> 
>> Mick
>> 
>> On 06/08/2020 09:06, Martin Patzak wrote:
>>> It looks like your timing has improved after all!
>>> 
>>> in your original Python-code you could time every read for each sensor.
>>> I have also powered sensors and a read is usually faster than 0.1 seconds.
>>> I log in a file if the read took longer than 0.3 seconds, which is almost never the case.
>>> I also log in the file if the whole reading loop took longer than 3 seconds, which again is almost never the case.
>>> 
>>> I also log if the error of the 1wire bus changes.
>>> 
>>> I read 25 sensors every full and every half minute, so maybe you could implement a delay as well and see if things get more consistent.
>>> Do you need to read so fast in a loop for you application?
>>> 
>>> What else is running on your machine? You could run top in parallel to your python loop.
>>> 
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> Owfs-developers mailing list
>> Owf...@li... <mailto:Owf...@li...>
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers <https://lists.sourceforge.net/lists/listinfo/owfs-developers>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

[Martin P. <Mar...@GM...>]

Thank you Stefano

On 06.08.20 16:19, Stefano Miccoli via Owfs-developers wrote:
> I agree that using the “persistent” network object for the present use
> case could speed up things, see
> <https://pyownet.readthedocs.io/en/latest/protocol.html#persistent-vs-non-persistent-proxy-objects>
>
>
> However the correct call to obtain a persistent object is
>
>     owp = pyownet.protocol.proxy(persistent=True)
>
> Stefano
>
>
> PS
>
> In the example code provided there is no need to close the connection,
> but the typical usage pattern is
>
> with owp:
> # loop reading sensors, persistent connection is open
> # do some work, persistent connection is closed
>
> which ensures that the persistent connection is closed upon exit of
> the `with` block and does not remain open when the program is not
> querying owserver.
>
> E.g.
>
> def main():
>     sen_lst = [
>         "Solar_Pnl_1A",
>         "Solar_Pnl_2A",
>         "Solar_Pnl_1B",
>         "Pool_Sol_X",
>         "Pool_CH_X",
>         "DHW_Mid_Top",
>         "DHW_Mid_Btm",
>         "DHW_Top",
>         "Temp5",
>         "Temp19",
>         "Temp20",
>         "Temp21",
>         "Temp22",
>         "Temp23",
>         "Temp25",
>         "Temp26",
>         "Temp27",
>         "Temp29",
>         "Temp30",
>     ]
>     prop_lst = ["/type", "/power", "/latesttemp"]
>     owp = pyownet.protocol.proxy(persistent=True)
>     while True:
>         start = time.time()
>         with owp:
>             # persistent socket is open!
>             owp.write("/simultaneous/temperature", b"1")
>             time.sleep(1)
>             print("start of sensor_read.py")
>             for p in prop_lst:
>                 print("%s  " % p, end="")
>             print("")
>             for sen in sen_lst:
>                 print("\n%s " % sen, end="")
>                 for prop in prop_lst:
>                     try:
>                         print(
>                             "%s  " % (owp.read("/uncached/" + sen +
> prop).decode()), end=""
>                         )
>                     except:
>                         print("failed! ", end="")
>             endt = time.time() - start
>             print("\nTime = %f" % endt)
>         # out of with block persistent socket is closed
> sleep(30) # do some other work, and then start again
>
>
>> On 6 Aug 2020, at 13:31, Martin Patzak <Mar...@GM...
>> <mailto:Mar...@GM...>> wrote:
>>
>> I read the CRC16 attribute from /statistics
>>
>>     /CRC16_error = op.read('/statistics/errors/CRC16_errors')/
>>
>> where op is the persistent(!)  /pyownet/ object, created like this:
>>
>> /    from pyownet import protocol//
>> //
>> //    op = protocol.proxy(server,port=port)/
>>
>> On 06.08.20 11:23, Mick Sulley wrote:
>>>
>>> OK I will log read times and see what that shows.
>>>
>>> You say 'I also log if the error of the 1wire bus changes.' how do
>>> you do that?
>>>
>>> No I don't really need to read that fast, this is just a test setup
>>> to get a better understanding so I can hopefully fine tune my main
>>> system.
>>>
>>> There should not be anything else running.  I just tried running top
>>> at the same time, I monitored it at the point of the slow scan and
>>> didn't see anything else significant.
>>>
>>> Mick
>>>
>>> On 06/08/2020 09:06, Martin Patzak wrote:
>>>> It looks like your timing has improved after all!
>>>>
>>>> in your original Python-code you could time every read for each sensor.
>>>> I have also powered sensors and a read is usually faster than 0.1
>>>> seconds.
>>>> I log in a file if the read took longer than 0.3 seconds, which is
>>>> almost never the case.
>>>> I also log in the file if the whole reading loop took longer than 3
>>>> seconds, which again is almost never the case.
>>>>
>>>> I also log if the error of the 1wire bus changes.
>>>>
>>>> I read 25 sensors every full and every half minute, so maybe you
>>>> could implement a delay as well and see if things get more consistent.
>>>> Do you need to read so fast in a loop for you application?
>>>>
>>>> What else is running on your machine? You could run top in parallel
>>>> to your python loop.
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Owfs-developers mailing list
>>> Owf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>> _______________________________________________
>> Owfs-developers mailing list
>> Owf...@li...
>> <mailto:Owf...@li...>
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

[Martin P. <Mar...@GM...>]

looks like you are getting close :-)

I checked, and the only timeout of owserver that matches 120 is
//settings/timeout/presence


/
On 06.08.20 16:21, Mick Sulley wrote:
>
> Well this gets more curious.  I am now measuring the time for each
> read, reading type, power and latesttemp.  Time for all is generally <
> 0.1 seconds, but then when I hit the slow loop the read for type is
> around 0.7 seconds, the others still < 0.1 seconds.  I don't really
> need type so I removed it and re-tested, on slow loops the power read
> is around 0.7 seconds, latesttemp still < 0.1 seconds.  So I removed
> power as well, just reading latesttemp, on slow loops that is now
> around 0.7 seconds.  So it seems that at some point a sensor takes
> many times longer for its next read, irrespective of which field is read.
>
> I have now tested with 19, 11 and 2 sensors and the slow loop occurs
> every 120 seconds.  I am intrigued to know what causes this, any ideas?
>
> Thanks
>
> Mick
>
> On 06/08/2020 10:23, Mick Sulley wrote:
>>
>> OK I will log read times and see what that shows.
>>
>> You say 'I also log if the error of the 1wire bus changes.' how do
>> you do that?
>>
>> No I don't really need to read that fast, this is just a test setup
>> to get a better understanding so I can hopefully fine tune my main
>> system.
>>
>> There should not be anything else running.  I just tried running top
>> at the same time, I monitored it at the point of the slow scan and
>> didn't see anything else significant.
>>
>> Mick
>>
>> On 06/08/2020 09:06, Martin Patzak wrote:
>>> It looks like your timing has improved after all!
>>>
>>> in your original Python-code you could time every read for each sensor.
>>> I have also powered sensors and a read is usually faster than 0.1
>>> seconds.
>>> I log in a file if the read took longer than 0.3 seconds, which is
>>> almost never the case.
>>> I also log in the file if the whole reading loop took longer than 3
>>> seconds, which again is almost never the case.
>>>
>>> I also log if the error of the 1wire bus changes.
>>>
>>> I read 25 sensors every full and every half minute, so maybe you
>>> could implement a delay as well and see if things get more consistent.
>>> Do you need to read so fast in a loop for you application?
>>>
>>> What else is running on your machine? You could run top in parallel
>>> to your python loop.
>>>
>>>
>>
>>
>> _______________________________________________
>> Owfs-developers mailing list
>> Owf...@li...
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

[Mick S. <mi...@su...>]

Well this gets more curious.  I am now measuring the time for each read, 
reading type, power and latesttemp.  Time for all is generally < 0.1 
seconds, but then when I hit the slow loop the read for type is around 
0.7 seconds, the others still < 0.1 seconds.  I don't really need type 
so I removed it and re-tested, on slow loops the power read is around 
0.7 seconds, latesttemp still < 0.1 seconds.  So I removed power as 
well, just reading latesttemp, on slow loops that is now around 0.7 
seconds.  So it seems that at some point a sensor takes many times 
longer for its next read, irrespective of which field is read.

I have now tested with 19, 11 and 2 sensors and the slow loop occurs 
every 120 seconds.  I am intrigued to know what causes this, any ideas?

Thanks

Mick

On 06/08/2020 10:23, Mick Sulley wrote:
>
> OK I will log read times and see what that shows.
>
> You say 'I also log if the error of the 1wire bus changes.' how do you 
> do that?
>
> No I don't really need to read that fast, this is just a test setup to 
> get a better understanding so I can hopefully fine tune my main system.
>
> There should not be anything else running.  I just tried running top 
> at the same time, I monitored it at the point of the slow scan and 
> didn't see anything else significant.
>
> Mick
>
> On 06/08/2020 09:06, Martin Patzak wrote:
>> It looks like your timing has improved after all!
>>
>> in your original Python-code you could time every read for each sensor.
>> I have also powered sensors and a read is usually faster than 0.1 
>> seconds.
>> I log in a file if the read took longer than 0.3 seconds, which is 
>> almost never the case.
>> I also log in the file if the whole reading loop took longer than 3 
>> seconds, which again is almost never the case.
>>
>> I also log if the error of the 1wire bus changes.
>>
>> I read 25 sensors every full and every half minute, so maybe you 
>> could implement a delay as well and see if things get more consistent.
>> Do you need to read so fast in a loop for you application?
>>
>> What else is running on your machine? You could run top in parallel 
>> to your python loop.
>>
>>
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

[Stefano M. <mo...@ic...>]

I agree that using the “persistent” network object for the present use case could speed up things, see <https://pyownet.readthedocs.io/en/latest/protocol.html#persistent-vs-non-persistent-proxy-objects <https://pyownet.readthedocs.io/en/latest/protocol.html#persistent-vs-non-persistent-proxy-objects>>

However the correct call to obtain a persistent object is

    owp = pyownet.protocol.proxy(persistent=True)

Stefano


PS

In the example code provided there is no need to close the connection, but the typical usage pattern is

	with owp:
		# loop reading sensors, persistent connection is open
	# do some work, persistent connection is closed

which ensures that the persistent connection is closed upon exit of the `with` block and does not remain open when the program is not querying owserver.

E.g.

def main():
    sen_lst = [
        "Solar_Pnl_1A",
        "Solar_Pnl_2A",
        "Solar_Pnl_1B",
        "Pool_Sol_X",
        "Pool_CH_X",
        "DHW_Mid_Top",
        "DHW_Mid_Btm",
        "DHW_Top",
        "Temp5",
        "Temp19",
        "Temp20",
        "Temp21",
        "Temp22",
        "Temp23",
        "Temp25",
        "Temp26",
        "Temp27",
        "Temp29",
        "Temp30",
    ]
    prop_lst = ["/type", "/power", "/latesttemp"]
    owp = pyownet.protocol.proxy(persistent=True)
    while True:
        start = time.time()
        with owp:
            # persistent socket is open!
            owp.write("/simultaneous/temperature", b"1")
            time.sleep(1)
            print("start of sensor_read.py")
            for p in prop_lst:
                print("%s  " % p, end="")
            print("")
            for sen in sen_lst:
                print("\n%s " % sen, end="")
                for prop in prop_lst:
                    try:
                        print(
                            "%s  " % (owp.read("/uncached/" + sen + prop).decode()), end=""
                        )
                    except:
                        print("failed! ", end="")
            endt = time.time() - start
            print("\nTime = %f" % endt)
        # out of with block persistent socket is closed
	sleep(30) # do some other work, and then start again


> On 6 Aug 2020, at 13:31, Martin Patzak <Mar...@GM...> wrote:
> 
> I read the CRC16 attribute from /statistics
> 
>     CRC16_error = op.read('/statistics/errors/CRC16_errors')
> 
> where op is the persistent(!)  pyownet object, created like this:
> 
>     from pyownet import protocol
> 
>     op = protocol.proxy(server,port=port)
> 
> On 06.08.20 11:23, Mick Sulley wrote:
>> OK I will log read times and see what that shows.
>> 
>> You say 'I also log if the error of the 1wire bus changes.' how do you do that?
>> 
>> No I don't really need to read that fast, this is just a test setup to get a better understanding so I can hopefully fine tune my main system.
>> 
>> There should not be anything else running.  I just tried running top at the same time, I monitored it at the point of the slow scan and didn't see anything else significant.
>> 
>> Mick
>> 
>> On 06/08/2020 09:06, Martin Patzak wrote:
>>> It looks like your timing has improved after all!
>>> 
>>> in your original Python-code you could time every read for each sensor.
>>> I have also powered sensors and a read is usually faster than 0.1 seconds.
>>> I log in a file if the read took longer than 0.3 seconds, which is almost never the case.
>>> I also log in the file if the whole reading loop took longer than 3 seconds, which again is almost never the case.
>>> 
>>> I also log if the error of the 1wire bus changes.
>>> 
>>> I read 25 sensors every full and every half minute, so maybe you could implement a delay as well and see if things get more consistent.
>>> Do you need to read so fast in a loop for you application?
>>> 
>>> What else is running on your machine? You could run top in parallel to your python loop.
>>> 
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> Owfs-developers mailing list
>> Owf...@li... <mailto:Owf...@li...>
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers <https://lists.sourceforge.net/lists/listinfo/owfs-developers>
> 
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

[Martin P. <Mar...@GM...>]

I read the CRC16 attribute from /statistics

    /CRC16_error = op.read('/statistics/errors/CRC16_errors')/

where op is the persistent(!)  /pyownet/ object, created like this:

/    from pyownet import protocol//
//
//    op = protocol.proxy(server,port=port)/

On 06.08.20 11:23, Mick Sulley wrote:
>
> OK I will log read times and see what that shows.
>
> You say 'I also log if the error of the 1wire bus changes.' how do you
> do that?
>
> No I don't really need to read that fast, this is just a test setup to
> get a better understanding so I can hopefully fine tune my main system.
>
> There should not be anything else running.  I just tried running top
> at the same time, I monitored it at the point of the slow scan and
> didn't see anything else significant.
>
> Mick
>
> On 06/08/2020 09:06, Martin Patzak wrote:
>> It looks like your timing has improved after all!
>>
>> in your original Python-code you could time every read for each sensor.
>> I have also powered sensors and a read is usually faster than 0.1
>> seconds.
>> I log in a file if the read took longer than 0.3 seconds, which is
>> almost never the case.
>> I also log in the file if the whole reading loop took longer than 3
>> seconds, which again is almost never the case.
>>
>> I also log if the error of the 1wire bus changes.
>>
>> I read 25 sensors every full and every half minute, so maybe you
>> could implement a delay as well and see if things get more consistent.
>> Do you need to read so fast in a loop for you application?
>>
>> What else is running on your machine? You could run top in parallel
>> to your python loop.
>>
>>
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

[Mick S. <mi...@su...>]

OK I will log read times and see what that shows.

You say 'I also log if the error of the 1wire bus changes.' how do you 
do that?

No I don't really need to read that fast, this is just a test setup to 
get a better understanding so I can hopefully fine tune my main system.

There should not be anything else running.  I just tried running top at 
the same time, I monitored it at the point of the slow scan and didn't 
see anything else significant.

Mick

On 06/08/2020 09:06, Martin Patzak wrote:
> It looks like your timing has improved after all!
>
> in your original Python-code you could time every read for each sensor.
> I have also powered sensors and a read is usually faster than 0.1 seconds.
> I log in a file if the read took longer than 0.3 seconds, which is 
> almost never the case.
> I also log in the file if the whole reading loop took longer than 3 
> seconds, which again is almost never the case.
>
> I also log if the error of the 1wire bus changes.
>
> I read 25 sensors every full and every half minute, so maybe you could 
> implement a delay as well and see if things get more consistent.
> Do you need to read so fast in a loop for you application?
>
> What else is running on your machine? You could run top in parallel to 
> your python loop.
>
>

Re: [Owfs-developers] Simultaneous not working

[Martin P. <Mar...@GM...>]

It looks like your timing has improved after all!

in your original Python-code you could time every read for each sensor.
I have also powered sensors and a read is usually faster than 0.1 seconds.
I log in a file if the read took longer than 0.3 seconds, which is
almost never the case.
I also log in the file if the whole reading loop took longer than 3
seconds, which again is almost never the case.

I also log if the error of the 1wire bus changes.

I read 25 sensors every full and every half minute, so maybe you could
implement a delay as well and see if things get more consistent.
Do you need to read so fast in a loop for you application?

What else is running on your machine? You could run top in parallel to
your python loop.

On 06.08.20 00:20, Mick Sulley wrote:
>
> OK I've done more testing, owhttpd was running and a web page open, I
> closed that and killed owttpd but it didn't seem to make any difference. 
>
>     From what you write it seems there's another process accessing the
>     sensors concurrently. Maybe a kernel driver? Check that first.
>
> I don't think there is anything else accessing them, lsmod|grep w1
> returned nothing but beyond that I don't know how to find out.
>
> I just tried running a shell script
> owwrite /simultaneous/temperature 1
> sleep 1s
> owread /uncached/Temp19/latesttemp
> owread /uncached/Temp20/latesttemp
> owread /uncached/Temp21/latesttemp
> owread /uncached/Temp22/latesttemp
> owread /uncached/Temp23/latesttemp
> owread /uncached/Temp25/latesttemp
> owread /uncached/Temp26/latesttemp
> owread /uncached/Temp27/latesttemp
> owread /uncached/Temp29/latesttemp
> echo
> echo 'Time ' $SECONDS
>
> I ran it repeatedly, it mostly takes 1 to 2 seconds, but after around
> 40 runs there is one that takes around 9 seconds.
>
> I also ran some tests with Python code and more sensors, again it
> looks to be working fine, but every 110 seconds or so it takes about 4
> times as long to read.  I looked at the timeout settings but the only
> one close to that was presence at 120, so I changed that to 10 and it
> made no difference, so it is not that.  Any ideas?
>
> Thanks for your help guys, much appreciated.
>
> Mick
>
>
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

[Mick S. <mi...@su...>]

OK I've done more testing, owhttpd was running and a web page open, I 
closed that and killed owttpd but it didn't seem to make any difference.

     From what you write it seems there's another process accessing the
    sensors concurrently. Maybe a kernel driver? Check that first.

I don't think there is anything else accessing them, lsmod|grep w1 
returned nothing but beyond that I don't know how to find out.

I just tried running a shell script
owwrite /simultaneous/temperature 1
sleep 1s
owread /uncached/Temp19/latesttemp
owread /uncached/Temp20/latesttemp
owread /uncached/Temp21/latesttemp
owread /uncached/Temp22/latesttemp
owread /uncached/Temp23/latesttemp
owread /uncached/Temp25/latesttemp
owread /uncached/Temp26/latesttemp
owread /uncached/Temp27/latesttemp
owread /uncached/Temp29/latesttemp
echo
echo 'Time ' $SECONDS

I ran it repeatedly, it mostly takes 1 to 2 seconds, but after around 40 
runs there is one that takes around 9 seconds.

I also ran some tests with Python code and more sensors, again it looks 
to be working fine, but every 110 seconds or so it takes about 4 times 
as long to read.  I looked at the timeout settings but the only one 
close to that was presence at 120, so I changed that to 10 and it made 
no difference, so it is not that.  Any ideas?

Thanks for your help guys, much appreciated.

Mick

Re: [Owfs-developers] Simultaneous not working

[Jan K. <jj...@gm...>]

Am 05.08.20 um 00:39 schrieb Mick Sulley:
> Running v3.2p3 on Raspberry Pi,  I have set up some DS18B20 sensors on a
> test system, all of them are powered, but simultaneous does not seem to
> be working
>
Triggering /temperature/simultaneous just sends "Skip ROM, Convert T" on
the bus.

If you never ever read .../<id>/temperature nodes, there's no waiting
time imposed by ofws. Reading /uncached/<id>/latesttemp reads the
current scratchpad from the sensor.

However, I'm not sure if the sensor itself imposes a waiting time for
reading the scratchpad while a conversion is active. In that case, owfs
would wait for it to respond.



>
> The code is below, when I run it the first loop takes 16 seconds then it
> loops at 3 seconds for a while, then a 16 second etc. so it looks like
> it does slow individual conversions, then uses cached values until they
> expire, then another slow individual conversion, etc.  Have I got
> something wrong here?
>
> #!/usr/bin/python3
>
> # sensor_read.py
>
> import pyownet
> import time
>
> def main():
>     owp = pyownet.protocol.proxy()
>     while True:
>         start = time.time()
>         owp.write('/simultaneous/temperature', b'1')
>         time.sleep(1)
>         print('start of sensor_read.py')
>         sen_lst = ['Solar_Pnl_1A', 'Solar_Pnl_2A','Solar_Pnl_1B',
> 'Pool_Sol_X', 'Pool_CH_X', 'DHW_Mid_Top', 'DHW_Mid_Btm',
> 'DHW_Top','Temp5', 'Temp19', 'Temp20','Temp21', 'Temp22', 'Temp23',
> 'Temp25', 'Temp26', 'Temp27', 'Temp29',  'Temp30']
>         prop_lst =  ['/type', '/power', '/latesttemp']
>         for p in prop_lst:
>             print('%s  ' %p,  end = '')
>         print('')
>         for sen in sen_lst:
>             print('\n%s ' %sen, end = '')
>             for prop in prop_lst:
>                 try:
>                     print('%s  ' %(owp.read('/uncached/' + sen +
> prop).decode()),  end = '')
>                 except:
>                     print('failed! ',    end = '')
>         endt = time.time() - start
>         print('\nTime = %f' %endt)
>
> if __name__ == "__main__":
>     main()
>
>
I'm not too familiar with Python but this looks straightforward and okay.

From what you write it seems there's another process accessing the
sensors concurrently. Maybe a kernel driver? Check that first.

Kind regards

	Jan

Re: [Owfs-developers] Simultaneous not working

[Mick S. <mi...@su...>]

I based my code on a mail from Jan 13/3/2020 which said the best way was

$ owwrite /simultaneous/temperature 1
$ sleep 1s
$ owread /uncached/<sensor0id>/latesttemp
$ owread /uncached/<sensor1id>/latesttemp
$ owread /uncached/<sensor2id>/latesttemp

I was thinking that the problem may be with my Python code, but I have 
just tried it with a bash script and writing to simultaneous/temperature 
make no difference.  I have tried it reading latesttemp and also 
temperature.

I am really confused now.

Mick


On 05/08/2020 09:15, Martin Patzak wrote:
> ... actually I checked my current code and I saw, that I do not read 
> /latesttemp, but read from /uncached/id/temperature
> so reading from /uncached does not trigger a new conversion. Only when 
> you read a second time without triggering /simultaneous
> I also saw that I increased the wait after issuing /simulataneous 
> command to 2 seconds, so I must have had issues at the time...
>
>
> On 05.08.20 09:23, Martin Patzak wrote:
>> Hi Mick,
>>
>> by reading the /uncached value, you are causing a new conversion.
>> Read only /latesttemp and it should work fine.
>>
>> here is my test program, when I first tested simultaneous and pyownet:
>>
>>> import time
>>> from pyownet import protocol
>>>
>>> op = protocol.proxy("razmaban",port=4304)
>>> error = 0
>>> error_old = None
>>>
>>>
>>> while True:
>>>
>>>     op.write('/simultaneous/temperature', '1')
>>>
>>>     time.sleep(1)   # give the sensors time to convert their temps
>>>
>>>     print '...'
>>>
>>>     sensed = op.read('/28.676A20060000/latesttemp')
>>>     print sensed
>>>
>>>     sensed = op.read('/28.DD5915020000/latesttemp')
>>>     print sensed
>>
>>
>> Marty
>>
>> On 05.08.20 00:39, Mick Sulley wrote:
>>> Running v3.2p3 on Raspberry Pi,  I have set up some DS18B20 sensors 
>>> on a test system, all of them are powered, but simultaneous does not 
>>> seem to be working
>>>
>>> The code is below, when I run it the first loop takes 16 seconds 
>>> then it loops at 3 seconds for a while, then a 16 second etc. so it 
>>> looks like it does slow individual conversions, then uses cached 
>>> values until they expire, then another slow individual conversion, 
>>> etc.  Have I got something wrong here?
>>>
>>> Thanks
>>>
>>> Mick
>>>
>>> #!/usr/bin/python3
>>>
>>> # sensor_read.py
>>>
>>> import pyownet
>>> import time
>>>
>>> def main():
>>>     owp = pyownet.protocol.proxy()
>>>     while True:
>>>         start = time.time()
>>>         owp.write('/simultaneous/temperature', b'1')
>>>         time.sleep(1)
>>>         print('start of sensor_read.py')
>>>         sen_lst = ['Solar_Pnl_1A', 'Solar_Pnl_2A','Solar_Pnl_1B', 
>>> 'Pool_Sol_X', 'Pool_CH_X', 'DHW_Mid_Top', 'DHW_Mid_Btm', 
>>> 'DHW_Top','Temp5', 'Temp19', 'Temp20','Temp21', 'Temp22', 'Temp23', 
>>> 'Temp25', 'Temp26', 'Temp27', 'Temp29',  'Temp30']
>>>         prop_lst =  ['/type', '/power', '/latesttemp']
>>>         for p in prop_lst:
>>>             print('%s  ' %p,  end = '')
>>>         print('')
>>>         for sen in sen_lst:
>>>             print('\n%s ' %sen, end = '')
>>>             for prop in prop_lst:
>>>                 try:
>>>                     print('%s  ' %(owp.read('/uncached/' + sen + 
>>> prop).decode()),  end = '')
>>>                 except:
>>>                     print('failed! ',    end = '')
>>>         endt = time.time() - start
>>>         print('\nTime = %f' %endt)
>>>
>>> if __name__ == "__main__":
>>>     main()
>>>
>>>
>>>
>>> _______________________________________________
>>> Owfs-developers mailing list
>>> Owf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>>
>>
>> _______________________________________________
>> Owfs-developers mailing list
>> Owf...@li...
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>

Re: [Owfs-developers] Simultaneous not working

[Martin P. <Mar...@GM...>]

... actually I checked my current code and I saw, that I do not read
/latesttemp, but read from /uncached/id/temperature
so reading from /uncached does not trigger a new conversion. Only when
you read a second time without triggering /simultaneous
I also saw that I increased the wait after issuing /simulataneous
command to 2 seconds, so I must have had issues at the time...


On 05.08.20 09:23, Martin Patzak wrote:
> Hi Mick,
>
> by reading the /uncached value, you are causing a new conversion.
> Read only /latesttemp and it should work fine.
>
> here is my test program, when I first tested simultaneous and pyownet:
>
>> import time
>> from pyownet import protocol
>>
>> op = protocol.proxy("razmaban",port=4304)
>> error = 0
>> error_old = None
>>
>>
>> while True:
>>
>>     op.write('/simultaneous/temperature', '1')
>>
>>     time.sleep(1)   # give the sensors time to convert their temps
>>
>>     print '...'
>>
>>     sensed = op.read('/28.676A20060000/latesttemp')
>>     print sensed
>>
>>     sensed = op.read('/28.DD5915020000/latesttemp')
>>     print sensed
>
>
> Marty
>
> On 05.08.20 00:39, Mick Sulley wrote:
>> Running v3.2p3 on Raspberry Pi,  I have set up some DS18B20 sensors
>> on a test system, all of them are powered, but simultaneous does not
>> seem to be working
>>
>> The code is below, when I run it the first loop takes 16 seconds then
>> it loops at 3 seconds for a while, then a 16 second etc. so it looks
>> like it does slow individual conversions, then uses cached values
>> until they expire, then another slow individual conversion, etc. 
>> Have I got something wrong here?
>>
>> Thanks
>>
>> Mick
>>
>> #!/usr/bin/python3
>>
>> # sensor_read.py
>>
>> import pyownet
>> import time
>>
>> def main():
>>     owp = pyownet.protocol.proxy()
>>     while True:
>>         start = time.time()
>>         owp.write('/simultaneous/temperature', b'1')
>>         time.sleep(1)
>>         print('start of sensor_read.py')
>>         sen_lst = ['Solar_Pnl_1A', 'Solar_Pnl_2A','Solar_Pnl_1B',
>> 'Pool_Sol_X', 'Pool_CH_X', 'DHW_Mid_Top', 'DHW_Mid_Btm',
>> 'DHW_Top','Temp5', 'Temp19', 'Temp20','Temp21', 'Temp22', 'Temp23',
>> 'Temp25', 'Temp26', 'Temp27', 'Temp29',  'Temp30']
>>         prop_lst =  ['/type', '/power', '/latesttemp']
>>         for p in prop_lst:
>>             print('%s  ' %p,  end = '')
>>         print('')
>>         for sen in sen_lst:
>>             print('\n%s ' %sen, end = '')
>>             for prop in prop_lst:
>>                 try:
>>                     print('%s  ' %(owp.read('/uncached/' + sen +
>> prop).decode()),  end = '')
>>                 except:
>>                     print('failed! ',    end = '')
>>         endt = time.time() - start
>>         print('\nTime = %f' %endt)
>>
>> if __name__ == "__main__":
>>     main()
>>
>>
>>
>> _______________________________________________
>> Owfs-developers mailing list
>> Owf...@li...
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

[Martin P. <Mar...@GM...>]

Hi Mick,

by reading the /uncached value, you are causing a new conversion.
Read only /latesttemp and it should work fine.

here is my test program, when I first tested simultaneous and pyownet:

> import time
> from pyownet import protocol
>
> op = protocol.proxy("razmaban",port=4304)
> error = 0
> error_old = None
>
>
> while True:
>
>     op.write('/simultaneous/temperature', '1')
>
>     time.sleep(1)   # give the sensors time to convert their temps
>
>     print '...'
>
>     sensed = op.read('/28.676A20060000/latesttemp')
>     print sensed
>
>     sensed = op.read('/28.DD5915020000/latesttemp')
>     print sensed


Marty

On 05.08.20 00:39, Mick Sulley wrote:
> Running v3.2p3 on Raspberry Pi,  I have set up some DS18B20 sensors on
> a test system, all of them are powered, but simultaneous does not seem
> to be working
>
> The code is below, when I run it the first loop takes 16 seconds then
> it loops at 3 seconds for a while, then a 16 second etc. so it looks
> like it does slow individual conversions, then uses cached values
> until they expire, then another slow individual conversion, etc.  Have
> I got something wrong here?
>
> Thanks
>
> Mick
>
> #!/usr/bin/python3
>
> # sensor_read.py
>
> import pyownet
> import time
>
> def main():
>     owp = pyownet.protocol.proxy()
>     while True:
>         start = time.time()
>         owp.write('/simultaneous/temperature', b'1')
>         time.sleep(1)
>         print('start of sensor_read.py')
>         sen_lst = ['Solar_Pnl_1A', 'Solar_Pnl_2A','Solar_Pnl_1B',
> 'Pool_Sol_X', 'Pool_CH_X', 'DHW_Mid_Top', 'DHW_Mid_Btm',
> 'DHW_Top','Temp5', 'Temp19', 'Temp20','Temp21', 'Temp22', 'Temp23',
> 'Temp25', 'Temp26', 'Temp27', 'Temp29',  'Temp30']
>         prop_lst =  ['/type', '/power', '/latesttemp']
>         for p in prop_lst:
>             print('%s  ' %p,  end = '')
>         print('')
>         for sen in sen_lst:
>             print('\n%s ' %sen, end = '')
>             for prop in prop_lst:
>                 try:
>                     print('%s  ' %(owp.read('/uncached/' + sen +
> prop).decode()),  end = '')
>                 except:
>                     print('failed! ',    end = '')
>         endt = time.time() - start
>         print('\nTime = %f' %endt)
>
> if __name__ == "__main__":
>     main()
>
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owf...@li...
> https://lists.sourceforge.net/lists/listinfo/owfs-developers