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
