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