On Saturday, October 10, 2015 at 5:10 AM, Jan Kandziora j...@gmx.de wrote: >> in the new logs I see changes that persist for less than two seconds. >> The occasional error readings also persist for less than two seconds: >> > If you don't read /uncached/, it's pretty clear owfs will only sample > temperatures each 15 seconds, because the volatile cache timeout is 15 > seconds. Please check that first. I think I'm finally breaking through some of my original confusion. The first thing I picked up about OWFS was that it creates directories and files that appear in the user file system. In my w1 installation, that structure didn't appear where it was expected - but a somewhat similar structure appeared at: --- root@arm:/sys/bus/w1/devices/28-0000008847d6# ls driver id name power subsystem uevent w1_slave root@arm:/sys/bus/w1/devices/28-0000008847d6# cat w1_slave c1 01 4b 46 7f ff 0f 10 38 : crc=38 YES c1 01 4b 46 7f ff 0f 10 38 t=28062 --- and at: --- root@arm:/sys/devices/w1_bus_master1# ls -al 28-0000008847d6 28-000000884d88 driver -> ../../bus/w1/drivers/w1_master_driver power subsystem -> ../../bus/w1 uevent ... root@arm:/sys/devices/w1_bus_master1/28-0000008847d6# ls driver id name power subsystem uevent w1_slave root@arm:/sys/devices/w1_bus_master1/28-0000008847d6# cat w1_slave c1 01 4b 46 7f ff 0f 10 38 : crc=38 YES c1 01 4b 46 7f ff 0f 10 38 t=28062 --- I see now that is created by w1, independent of OWFS! The actual owfs module that creates the owfs filesystem view isn't even installed here. My 10 second interval comes from: root@arm:/sys/devices/w1_bus_master1# cat w1_master_timeout 10
My Python code reads "/sys/bus/w1/devices/28-000000884d88/w1_slave" which apparently behaves like the OWFS "uncached" read. When Python or even just a command line cat reads that "file", it forces w1 to read the physical sensor, with a delay of 750 mS before the response appears. (That's why even after I removed all the intentional delays from Python, it still took 1.6 seconds to query two sensors.) >> The "-62" errors always look like that - one line of all "ff" with a bad >> CRC, followed by the correct bits with a bad temperature. > These are from linux/drivers/w1/slaves/w1_therm.c, around line 250. > > These CRC errors aren't reported to owfs. The reading is just ignored > and the old value sticks in the chip structure the w1 driver manages. So > OWFS isn't aware there was an error at all. So I want to be querying owserver instead of w1? >> I'm further mystified... How can the files change so frequently >> in-between actual reads? >> > Because other parts of the systems are polling w1. Like my own test program! I didn't notice the one that runs constantly because it only queries once per five minutes. I didn't happen to turn on the scope while I was running the 1.6 second version until just now... I'm pretty sure nothing else on a BBB uses w1. It is normally not enabled at all, the default HDMI uses those GPIOs. And it only finds my two 18B20 chips, no other buses or devices are active. > That sure is because the owfs server programs are started from a script > which tries every few seconds to start them and usually that fails > because you have specified --w1 for owserver in the owfs.conf file. > > As soon the w1 hardware is there, UDEV is loading the w1 kernel driver > and the next attempt to start owserver with --w1 succeeds. In the next > try, the start of owhttpd et al also succeeds because owserver is > finally there. I think I finally understand how the owfs modules get started. There is the file in /etc/init.d: --- ubuntu@arm:/etc/init.d$ cat owserver #!/bin/sh ### BEGIN INIT INFO # Provides: owserver # Required-Start: $remote_fs $syslog $network $named # Required-Stop: $remote_fs $syslog $network $named # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: 1-wire TCP server # Description: Start and stop a TCP server for 1-wire control. ### END INIT INFO PATH=/sbin:/bin:/usr/sbin:/usr/bin CONFFILE=/etc/owfs.conf ... --- And symbolic links in the /etc/rc#.d directories, created by apt-get and update-rc.d; for example: --- ubuntu@arm:/etc$ ls rc5.d README S20hostapd S20owhttpd S05loadcpufreq S20kerneloops S20owserver S19cpufrequtils S20owftpd S20rsync --- Link names beginning with 'S' get started for the run level # in "rc#.d". >> The web page says, "The timeouts are read/writable values found under >> /settings/timeout/[volatile|stable|directory|presence]", but I can't >> find that path on my system. >> > This is a path inside the owfs system, not inside the root file system.> > > If you want to have these pseudo-paths mapped into the real filesystem > of your machine, for example for accessing it with echo and cat, you > have to use the "owfs" tool. I don't recommend it because it adds more > complexity to your machine and you gain very little from it. Once again I've been horribly confused by trying to convert commands and paths I see people in this list talking about for the actual owfs module, with my somewhat similar w1 virtual file system. I don't even have owfs itself installed - only owserver, httpd, and ftpd! I don't have owshell installed, either - apparently it isn't part of the Ubuntu package, and isn't available from apt-get. (I suppose I should build my own install, but so far I've spent all my energy trying to learn to use what I already have.) So are you saying owshell might be able to read and write config values that the owhttpd can't? Maybe pyownet could do the same? I just installed it and got it to read temperatures - and if it is read again quickly, it returns results instantly. I guess it is interacting with the 15 second owserver timeout. Sometimes I can wait almost 15 seconds and still get an instant response, but other times it pauses to read again less than five seconds from the last read. So getting back to the original issues... <https://www.kernel.org/doc/Documentation/w1/w1.generic> ----- It is possible that between [write control buffer] and [reading], w1 master thread will reset bus for searching and slave device will be even removed, but in this case 0xff will be read, since no device was selected. ... If you have a w1 bus that never changes (you don't add or remove devices), you can set the module parameter search_count to a small positive number for an initially small number of bus searches. Alternatively it could be set to zero, then manually add the slave device serial numbers by w1_master_add device file. The w1_master_add and w1_master_remove files generally only make sense when searching is disabled, as a search will redetect manually removed devices that are present and timeout manually added devices that aren't on the bus. Bus searches occur at an interval, specified as a sum of timeout and timeout_us module parameters (either of which may be 0) for as long as w1_master_search remains greater than 0 or is -1. Each search attempt decrements w1_master_search by 1 (down to 0) and increments w1_master_attempts by 1. ----- Sounds like maybe one could turn off the searches to eliminate the "all ff, -62" errors. I wonder if some glitch would then lose the sensors and without search active they wouldn't come back. But something isn't right about that explanation. I watched w1_master_attempts, and it is clearly counting the 10-second reads, not the much rarer bus reset and "all ff, -62" errors: --- root@arm:/sys/devices/w1_bus_master1# cat w1_master_attempts 2535945 root@arm:/sys/devices/w1_bus_master1# date Sat Oct 10 13:30:36 PDT 2015 root@arm:/sys/devices/w1_bus_master1# cat w1_master_attempts 2535946 root@arm:/sys/devices/w1_bus_master1# date Sat Oct 10 13:30:45 PDT 2015 root@arm:/sys/devices/w1_bus_master1# cat w1_master_attempts 2535947 root@arm:/sys/devices/w1_bus_master1# date Sat Oct 10 13:30:55 PDT 2015 root@arm:/sys/devices/w1_bus_master1# cat w1_master_attempts 2535948 --- They say: "w1_master_timeout - the delay in seconds between searches" and mine is clearly 10, so that doesn't seem to define the rare ~4 mS bus resets. If they were doing the long bus reset between every [write control buffer] and [reading], 0xff would always be read and they would never get any temperatures. Still mysteries here... And none of this has let me understand how changing the pullup value can change the temperatures! Loren | Loren Amelang | lo...@pacific.net | ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
