On Monday, October 12, 2015 at 5:03 AM, Jan Kandziora j...@gmx.de wrote: > With the owfs tools, you get network transparency, a wider range of > supported host adapters and slave devices and the cache. If you don't > need any of that, you gain nothing but complexity. Being able to peek at my system from a web browser instead of an SSH session is valuable. I will probably need an I2C or USB adapter in the real system. Versatility is worth some complexity.
> Maybe > your owhttpd is started with the -r or --readonly option for security > reasons? Check it with > > $ ps aux | grep owhttpd root 1145 0.0 0.1 20036 832 ? Ssl 2014 58:47 /usr/bin/owftpd -c /etc/owfs.conf --pid-file /var/run/owfs/owftpd.pid root 1245 0.0 0.2 21044 1080 ? Ss 2014 0:03 /usr/bin/owhttpd -c /etc/owfs.conf --pid-file /var/run/owfs/owhttpd.pid root 1333 0.0 0.2 53804 1196 ? Ssl 2014 0:48 /usr/bin/owserver -c /etc/owfs.conf --pid-file /var/run/owfs/owserver.pid (I've always wondered why owftpd shows all that runtime when I never touch it...) > This error will only happens if the search thread is doing the bus reset > during temperature conversion, because the other thread isn't aware it > can't read back the temperature after conversion before doing another > "Match ROM" command on that slave (it doesn't). > > But yes, disabling the w1 search thread would eliminate that error. I'm lost again. There is a temperature read every ten seconds, followed by a 480 uS "bus reset", a conversion setup, and a pause for conversion before the next ten second read. Separately, there is a thread which sends a bus reset and a search for sensors. If that search thread fires in the middle of a ten second conversion pause, it kills the conversion and the other thread will read all "ff" values - right so far? So how often does the search thread fire? Unless it is precisely integrated into the read process, it can't fire every ten seconds, or we'd never get any temperatures, right? They say: w1_master_timeout - (ro) the delay in seconds between searches and show mine as ten seconds. They say: Each search attempt ... increments w1_master_attempts by 1. and I see that happen every ten seconds. If they really do somehow combine a search with every temperature read every ten seconds, then what causes the "all ff, -62" errors, which are much rarer? It seems like the asynchronous search thread is a perfect explanation - if it only runs every few minutes. >> And none of this has let me understand how changing the pullup value >> can change the temperatures! >> > As the values CRAWL I expect it to be additonal heat either delivered to > the sensor through the wires or generated inside the sensor because of > some short-circuit condition. I have done a new experiment. I wrote a pyownet program which reads every one-tenth second (if it can). And I dug out an ancient device with a smooth ten-turn pot that goes from 0 ohms to 10000 ohms. In series with my clipped-on resistor, it dials from a total pullup of 1K to a total of 2.5K. (The first "cached" test included an additional 300 ohms in series; later tests avoided that.) The cached test is shown in: <http://psychoros.org/OWFS/OWFS_PullUpTest_cached.PNG> Spikes along the bottom are bus reads, nicely spaced at 15 seconds. On the upward ramp it read both sensors in the same slot (2+ seconds on the right hand scale). Later it began reading them separately, but close together, and faster (~1 second each). Here's the data for the "Unclip" rise: --- Python time seconds temp1 temp2 read pause (small values zeroed) 2015-10-12 13:15:24.777982 15:24.777982 26.5 27.125 0 2015-10-12 13:15:24.881038 15:24.881038 26.5 27.125 0 2015-10-12 13:15:24.980847 15:24.980847 26.5 27.125 0 2015-10-12 13:15:26.125298 15:26.125298 28.0625 27.125 1.144451 2015-10-12 13:15:26.225168 15:26.225168 28.0625 27.125 0 2015-10-12 13:15:26.324653 15:26.324653 28.0625 27.125 0 2015-10-12 13:15:26.424145 15:26.424145 28.0625 27.125 0 2015-10-12 13:15:26.526205 15:26.526205 28.0625 27.125 0 2015-10-12 13:15:26.625642 15:26.625642 28.0625 27.125 0 2015-10-12 13:15:26.725200 15:26.725200 28.0625 27.125 0 2015-10-12 13:15:26.825055 15:26.825055 28.0625 27.125 0 2015-10-12 13:15:26.926061 15:26.926061 28.0625 27.125 0 2015-10-12 13:15:28.070633 15:28.070633 28.0625 32.625 1.144572 2015-10-12 13:15:28.170094 15:28.170094 28.0625 32.625 0 2015-10-12 13:15:28.271270 15:28.271270 28.0625 32.625 0 2015-10-12 13:15:28.370662 15:28.370662 28.0625 32.625 0 --- The full rise is shown in a single read period, but of course that's 15 seconds between samples. So I made another program that reads "uncached", and only updates temp2 to make it faster: <http://psychoros.org/OWFS/OWFS_PullUpTest_uncached.PNG> Again, read delays along the bottom. Most of them very near the 1-second line (right scale). But a significant number at random times taking 2 or 3 seconds... The tallest spike in the center is a pause between two tests. Only temp2 is live. Raw data for the last sharp "Unclip" rise: --- Python time seconds temp1 temp2 read pause 2015-10-12 16:51:15.883207 51:15.883207 26.5 31.3125 1.07 2015-10-12 16:51:16.951788 51:16.951788 26.5 31.3125 1.07 2015-10-12 16:51:18.019880 51:18.019880 26.5 31.3750 1.07 2015-10-12 16:51:21.691823 51:21.691823 26.5 31.3750 3.67 2015-10-12 16:51:22.760226 51:22.760226 26.5 31.3125 1.07 2015-10-12 16:51:23.852932 51:23.852932 26.5 36.5000 1.09 2015-10-12 16:51:25.982257 51:25.982257 26.5 36.5000 2.13 2015-10-12 16:51:27.066210 51:27.066210 26.5 36.5000 1.08 2015-10-12 16:51:28.143298 51:28.143298 26.5 36.4375 1.08 2015-10-12 16:51:29.211272 51:29.211272 26.5 36.6250 1.07 --- Sure looks to me like the read temperature goes from 31.3125 to 36.5000 in 1.09 seconds, the smallest interval I know how to read. There is that curious bounce up to 31.3750 for two readings, followed by the 3.67 second read pause... But then another 31.3125 before the jump... Do you understand what's happening there? You may notice my "3197 ohms pullup plus 10K ohm pull down (accidental&)" label. I unclipped the end of the 10K pot I was using, and because the wiper was still connected, needed another way to support the pot near the wall cabinet where this is all happening. I clipped the far end of the 10K to what I thought was an isolated and insulated metal edge, but it turned out the clip managed to ground itself. Luckily it was 10K away from the active bus! But it shows that with only one sensor doing conversions, I can read wrong values with even less bus power than my 3197 ohm pullup - and the temperatures are even higher: --- 2015-10-12 16:44:00.570196 44:00.570196 26.5 31.3125 1.09 2015-10-12 16:44:01.657145 44:01.657145 26.5 31.2500 1.09 2015-10-12 16:44:02.770822 44:02.770822 26.5 31.9375 1.11 2015-10-12 16:44:03.847316 44:03.847316 26.5 38.3125 1.08 2015-10-12 16:44:04.918067 44:04.918067 26.5 38.2500 1.07 2015-10-12 16:44:05.987845 44:05.987845 26.5 38.3125 1.07 --- There is that curious 31.9375 precursor to the larger jump, but no long reads this time. The temperature change at the end of that error period is instantaneous and clean, but includes long reads: --- 2015-10-12 16:44:12.404259 44:12.404259 26.5 38.2500 1.08 2015-10-12 16:44:14.535900 44:14.535900 26.5 38.2500 2.13 2015-10-12 16:44:16.125988 44:16.125988 26.5 38.2500 1.59 2015-10-12 16:44:17.193745 44:17.193745 26.5 31.2500 1.07 2015-10-12 16:44:18.262280 44:18.262280 26.5 31.2500 1.07 2015-10-12 16:44:19.330395 44:19.330395 26.5 31.2500 1.07 --- If this was internal heating, I certainly would not expect less bus power to produce more heating. Another curiosity I just noticed. There are three places where reads take less than one second, and temperatures drop by a degree: --- 2015-10-12 16:44:27.929276 44:27.929276 26.5 31.2500 1.09 2015-10-12 16:44:28.717139 44:28.717139 26.5 29.8750 0.79 2015-10-12 16:44:29.787715 44:29.787715 26.5 31.3125 1.07 ... 2015-10-12 16:51:07.080564 51:07.080564 26.5 32.4375 1.07 2015-10-12 16:51:07.831505 51:07.831505 26.5 30.0625 0.75 2015-10-12 16:51:09.090268 51:09.090268 26.5 31.5625 1.26 ... 2015-10-12 16:51:45.285573 51:45.285573 26.5 31.3750 1.07 2015-10-12 16:51:46.033067 51:46.033067 26.5 30.2500 0.75 2015-10-12 16:51:47.102980 51:47.102980 26.5 31.3750 1.07 --- I don't believe I was affecting the bus at those points. I guess 750 mS is a possible bus read time, but apparently a normal read from pyownet adds ~300 mS of overhead. So somehow a wrongly low value appeared suspiciously soon... If you'd like to see all the data: <http://psychoros.org/OWFS/OWFStsvPy_PullUp_Test_(cached).xlsx> <http://psychoros.org/OWFS/OWFStsvPy_PullUp_Test_(uncached).xlsx> Still quite mystified, but thankful you've been willing to help me dig through this! Loren | Loren Amelang | lo...@pacific.net | ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
