OWSERVER(1) | One-Wire File System | OWSERVER(1) |
owserver - Backend server (daemon) for 1-wire control
owserver [ -c config ] -d serialport | -u | -s [host:]port -p tcp-port
1-wire is a wiring protocol and series of devices designed and manufactured by Dallas Semiconductor, Inc. The bus is a low-power low-speed low-connector scheme where the data line can also provide power.
Each device is uniquely and unalterably numbered during manufacture. There are a wide variety of devices, including memory, sensors (humidity, temperature, voltage, contact, current), switches, timers and data loggers. More complex devices (like thermocouple sensors) can be built with these basic devices. There are also 1-wire devices that have encryption included.
The 1-wire scheme uses a single bus master and multiple slaves on the same wire. The bus master initiates all communication. The slaves can be individually discovered and addressed using their unique ID.
Bus masters come in a variety of configurations including serial, parallel, i2c, network or USB adapters.
OWFS is a suite of programs that designed to make the 1-wire bus and its devices easily accessible. The underlying principle is to create a virtual filesystem, with the unique ID being the directory, and the individual properties of the device are represented as simple files that can be read and written.
Details of the individual slave or master design are hidden behind a consistent interface. The goal is to provide an easy set of tools for a software designer to create monitoring or control applications. There are some performance enhancements in the implementation, including data caching, parallel access to bus masters, and aggregation of device communication. Still the fundamental goal has been ease of use, flexibility and correctness rather than speed.
owserver (1) is the backend component of the OWFS 1-wire bus control system. owserver (1) arbitrates access to the bus from multiple client processes. The physical bus is usually connected to a serial or USB port, and other processes connect to owserver (1) over network sockets (tcp port). Communication can be local or over a network. Secure tunneling can be implemented using standard techniques.
Frontend clients include a filesystem representation: owfs (1) , and a webserver: owhttpd (1). Direct language bindings are also available, e.g: owperl (3). Several instances of each client can be initiated.
Each client can also connect directly to the physical bus, skipping owserver (1) but only one client can connect to the physical bus safely. Simultaneous access is prevented by the operating system for USB ports, but unfortunately not serial ports. The safe way to share access to the 1-wire bus is via owserver (1) with the clients connecting. Note: owserver (1) can connect to another owserver (1) process, though the utility of this technique is limited (perhaps as a readonly buffer?)
owserver (1) is by default multithreaded. Optional data caching is in the server, not clients, so all the clients gain efficiency.
These options specify the device (bus master) connecting the computer to the 1-wire bus. The 1-wire slaves are connected to the 1-wire bus, and the bus master connects to a port on the computer and controls the 1-wire bus. The bus master is either an actual physical device, the kernel w1 module, or an owserver (1).
At least one device option is required. There is no default. More than one device can be listed, and all will be used. (A logical union unless you explore the /bus.n/ directories.)
Linux and BSD enforce a security policy restricting access to hardware ports. You must have sufficient rights to access the given port or access will silently fail.
port specifies a serial port, e.g. /dev/ttyS0 or an USB port accessed as serial port, e.g. /dev/ttyUSB0
If OWFS was built with libftdi support, you may be able to
use the ftdi: prefix in any of the options as port to address
a FTDI-based USB device.
For details, see the FTDI ADDRESSING section.
The only supported true USB bus masters are based on the DS2490 chip. The most common is the DS9490R which has an included 1-wire ID slave with family code 81.
There are also bus masters based on the serial chip with a USB to serial conversion built in. These are supported by the serial bus master protocol.
I2C is 2 wire protocol used for chip-to-chip communication. The bus masters: DS2482-100, DS2482-101 and DS2482-800 can specify (via pin voltages) a subset of addresses on the i2c bus. Those choices are
i2c_address
port for i2c masters have the form /dev/i2c-0, /dev/i2c-1, ...
The DS2482-800 masters 8 1-wire buses and so will generate 8 /bus.n entries.
These bus masters communicate via the tcp/ip network protocol and so can be located anywhere on the network. The network_address is of the form tcp_address:port
E.g. 192.168.0.1:3000 or localhost:3000
Used for testing and development. No actual hardware is needed. Useful for separating the hardware development from the rest of the software design.
This a linux-specific option for using the operating system's access to bus masters. Root access is required and the implementation was still in progress as of owfs v2.7p12 and linux 2.6.30.
Bus masters are recognized and added dynamically. Details of the physical bus master are not accessible, bu they include USB, i2c and a number of GPIO designs on embedded boards.
Access is restrict to superuser due to the netlink broadcast protocol employed by w1. Multitasking must be configured (threads) on the compilation.
FTDI is a brand of USB-to-serial chips which are very common. If your serial device is connected via a USB serial dongle based on a FTDI chip, or if your adapter uses a built-in FTDI USB chip (for example, the LinkUSB), you can use this FTDI addressing.
The main benefit with this mode of access is that we can decrease the communication delay, yielding twice as fast 1-Wire communication in many cases.
The following values for port can be used to identify a
specific FTDI port in several of the serial devices options.
Note that this requires that OWFS is built with libftdi support, which might
not be the case in standard repositories.
The above formats are parsed fully by libftdi (minus the ftdi: prefix).
An additional format is supported, for certain bus types. This only specifies the USB serial number.
In order to run owserver (1) without root privileges - as you should, you must have sufficient permissions to the raw USB node your adapter is connected to e.g. "003/001" (usually at /proc/bus/usb/ or /dev/bus/usb/).
An easy way to achieve this would be using chown (1):
You can also write a udev (1) rule for your adapter:
Communication in FTDI mode accesses the RAW USB node and NOT the
serial USB node your OS might have created automatically e.g. /dev/ttyUSB0.
As a side effect, if existing, the serial USB node e.g. /dev/ttyUSB0 is
removed on successful starting of owserver (1). After it's
termination un- and re-plugging the adapter, or un- and reloading of the
module ftdi_sio will recreate the serial USB node.
owusbprobe is THE tool to find the information needed for
direct FTDI addressing
However this tool might not yet be packaged in your version. Alternatively you
can also use lsusb to find the usb node your adapter is connected to, and
then use lsusb again on this very node:
TCP port or IPaddress:port for owserver
Other OWFS programs will access owserver via this address. (e.g. owfs -s IP:port /1wire)
If no port is specified, the default well-known port (4304 -- assigned by the IANA) will be used.
Temperature scale used for data output. Celsius is the default.
Can also be changed within the program at /settings/units/temperature_scale
Pressure scale used for data output. Millibar is the default.
Can also be changed within the program at /settings/units/pressure_scale
Choose the representation of the 1-wire unique identifiers. OWFS uses these identifiers as unique directory names.
Although several display formats are selectable, all must be in family-id-crc8 form, unlike some other programs and the labelling on iButtons, which are crc8-id-family form.
Display format for the 1-wire devices. Each device has a 8byte address, consisting of:
Possible formats are f.i (default, 01.A1B2C3D4E5F6), fi fic f.ic f.i.c and fi.c
All formats are accepted as input, but the output will be in the specified format.
The address elements can be retrieved from a device entry in owfs by the family, id and crc8 properties, and as a whole with address. The reversed id and address can be retrieved as r_id and r_address.
Do we allow writing to the 1-wire bus (writing memory, setting switches, limits, PIOs)? The write option is available for symmetry, it's the default.
Places the PID -- process ID of owfs into the specified filename. Useful for startup scripts control.
Whether the program releases the console and runs in the background after evaluating command line options. background is the default.
--error_level=9 produces a lot of output
Name of an owfs (5) configuration file with more command line parameters
See also this man page and the web site http://www.owfs.org
Shows basic summary of options.
Version of this program and related libraries.
Timeouts for the bus masters were previously listed in Device options. Timeouts for the cache affect the time that data stays in memory. Default values are shown.
Seconds until a volatile property expires in the cache. Volatile properties are those (like temperature) that change on their own.
Can be changed dynamically at /settings/timeout/volatile
Seconds until a stable property expires in the cache. Stable properties are those that shouldn't change unless explicitly changed. Memory contents for example.
Can be changed dynamically at /settings/timeout/stable
Seconds until a directory listing expires in the cache. Directory lists are the 1-wire devices found on the bus.
Can be changed dynamically at /settings/timeout/directory
Seconds until the presence and bus location of a 1-wire device expires in the cache.
Can be changed dynamically at /settings/timeout/presence
There are also timeouts for specific program responses:
Seconds until the expected response from the owserver (1) is deemed tardy.
Can be changed dynamically at /settings/timeout/server
Seconds that an ftp session is kept alive.
Can be changed dynamically at /settings/timeout/ftp
These settings control the behavior of owserver (1) in granting and dropping persistent tcp connections. The default settings are shown.
In general no changes should be needed. In general the purpose is to limit total resource usage from an errant or rogue client.
Minimum seconds that a persistent tcp connection to owserver (1) is kept open. This is the limit used when the number of connections is above --clients_persistent_low
Maximum seconds that a persistent tcp connection to owserver (1) is kept open. This is the limit used when the number of connections is below --clients_persistent_low
Maximum number of persistent tcp connections to owserver (1) before connections start getting the more stringent time limitation --timeout_persistent_low
Maximum number of persistent tcp connections to before no more are allowed (only non-persistent at this point). owserver (1) before no more are allowed (only non-persistent at this point).
Reject DIRALL messages (requests directory as a single message), forcing client to use older DIR method (each element is an individual message)
Reject GET messages (lets owserver determine if READ or DIRALL is appropriate). Client will fall back to older methods.
Reject persistence in requests. All transactions will have to be new connections.
Interject many "keep-alive" (PING) responses. Usually PING responses are only sent when processing is taking a long time to inform client that owserver is still there.
owserver -p 3001 -d /dev/ttyS0 runs owserver on tcp port 3001 and connects to a physical 1-wire bus on a serial port.
owfs (1) owhttpd (1) owftpd (1) owserver (1) owdir (1) owread (1) owwrite (1) owpresent (1) owtap (1)
owfs (5) owtap (1) owmon (1)
owtcl (3) owperl (3) owcapi (3)
DS1427 (3) DS1904(3) DS1994 (3) DS2404 (3) DS2404S (3) DS2415 (3) DS2417 (3)
DS2401 (3) DS2411 (3) DS1990A (3)
DS1982 (3) DS1985 (3) DS1986 (3) DS1991 (3) DS1992 (3) DS1993 (3) DS1995 (3) DS1996 (3) DS2430A (3) DS2431 (3) DS2433 (3) DS2502 (3) DS2506 (3) DS28E04 (3) DS28EC20 (3)
DS2405 (3) DS2406 (3) DS2408 (3) DS2409 (3) DS2413 (3) DS28EA00 (3)
DS1822 (3) DS1825 (3) DS1820 (3) DS18B20 (3) DS18S20 (3) DS1920 (3) DS1921 (3) DS1821 (3) DS28EA00 (3) DS28E04 (3)
DS1922 (3)
DS2450 (3)
DS2890 (3)
DS2436 (3) DS2437 (3) DS2438 (3) DS2751 (3) DS2755 (3) DS2756 (3) DS2760 (3) DS2770 (3) DS2780 (3) DS2781 (3) DS2788 (3) DS2784 (3)
DS2423 (3)
LCD (3) DS2408 (3)
DS1977 (3)
DS2406 (3) -- TAI8570
http://www.owfs.org
Paul Alfille (paul.alfille@gmail.com)
2004 | OWSERVER Manpage |