Re: [Owfs-developers] Simultaneous not working

2020-08-07 Thread Stefano Miccoli via Owfs-developers 


> On 6 Aug 2020, at 21:42, Mick Sulley  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 999, 
> 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
 [email protected] 
 
 https://lists.sourceforge.net/lists/listinfo/owfs-developers 
 
>>> 
>>> 
>>> 
>>> ___
>>> Owfs-developers mailing list
>>> [email protected] 
>>> 
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers 
>>> 
>> 
> ___
> Owfs-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listi

Re: [Owfs-developers] Simultaneous not working

2020-08-07 Thread Martin Patzak 
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 999 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 999, 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

Re: [Owfs-developers] Simultaneous not working

2020-08-06 Thread Mick Sulley 
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 999 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 999, 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers




___
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

2020-08-06 Thread Martin Patzak 
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 999 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 999, 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
 [email protected]
 https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>>
>>>
>>> ___
>>> Owfs-developers mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>

___
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

2020-08-06 Thread Mick Sulley 

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 999, 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers



___
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


___
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

2020-08-06 Thread Stefano Miccoli via Owfs-developers 
Did you check if persistent=True makes any difference?

> On 6 Aug 2020, at 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
>> [email protected] 
>> 
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers 
>> 
> ___
> Owfs-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

___
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

2020-08-06 Thread Martin Patzak 
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
> 
>
>
> 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 > > 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
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>> ___
>> Owfs-developers mailing list
>> [email protected]
>> 
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
> ___
> Owfs-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

___
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

2020-08-06 Thread Martin Patzak 
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
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
> ___
> Owfs-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

___
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

2020-08-06 Thread Mick Sulley 
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
___
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

2020-08-06 Thread Stefano Miccoli via Owfs-developers 
I agree that using the “persistent” network object for the present use case 
could speed up things, see 
>

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  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
>> [email protected] 
>> 
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers 
>> 
> 
> ___
> Owfs-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

___
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

2020-08-06 Thread Martin Patzak 
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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

___
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

2020-08-06 Thread Mick Sulley 

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

2020-08-06 Thread Martin Patzak 
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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

___
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

2020-08-05 Thread Mick Sulley 
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

2020-08-05 Thread Jan Kandziora 
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 ...//temperature nodes, there's no waiting
time imposed by ofws. Reading /uncached//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



___
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

2020-08-05 Thread Mick Sulley 

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//latesttemp
$ owread /uncached//latesttemp
$ owread /uncached//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.676A2006/latesttemp')
    print sensed

    sensed = op.read('/28.DD591502/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
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers




___
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


___
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

2020-08-05 Thread Martin Patzak 
... 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.676A2006/latesttemp')
>>     print sensed
>>
>>     sensed = op.read('/28.DD591502/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
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
> ___
> Owfs-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

___
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Simultaneous not working

2020-08-05 Thread Martin Patzak 
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.676A2006/latesttemp')
>     print sensed
>
>     sensed = op.read('/28.DD591502/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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

___
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers