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