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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers