Table of Contents

Name

owserver - Backend server (daemon) for 1-wire control

Synopsis

owserver -c config ] -d serialport | -u | -s [host:]port -p tcp-port

Description

1-Wire

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 unalterably numbered during manufacture. There is 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 bus is accessed via one of a number of serial, parallel, i2c, network or USB adapters.

OWFS design

OWFS is a suite of programs that fundementally make the 1-wire bus and its devices easily accessible. The underlying priciple is to create a virtual filesystem, with the unique ID being the directory, and the individual properties of the device files.

There is optional data caching to improved performance, but possible confusion over stale data.

owserver

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.

Device Options

These options specify the 1-wire bus master the physically connects to the 1-wire bus. More than one can be specified. The result will be the logical union of all the specified bus masters. Individual adapters can be addressed as bus.0 bus.1 ...

At least one device option is required. There is no default.

Note that your operating system will likely restrict access to physical ports to authorised users.

-d /dev/ttyS0

Serial adapter. The address of the serial port is operating system-dependent. Adapters supported are the DS2480B-based DS9097U , iButtonLink's LINK in emulation mode, or the passive DS9097

-d /dev/i2c-0

Use i2c adapter 0. Based on the DS2482-100 or the DS2482-800. The DS2482-800 is interesting, it actually has 8 separately addressable 1-wire bus lines, and will appear as 8 separate busses.

-u --usb

USB adapter (based on the DS2490, like the DS9490R).

In general the operating system will assign the first avaliable adapter. Use the option: -u2 or --usb=2 for the second adapter. To use all the available USB adapters: -all or --usb=all

--LINK=/dev/ttyS0

The iButtonlink LINK adapter on serial port 0. The LINK uses it's own ascii communication protocol.

-s localhost:4304

Connect to an owserver at the listed network location.

--fake=10,12,28

Create a simulated bus with simulated devices (family codes 10,12 and 28 in this case). All the responses are random, and writing is not supported.

--tester=10,12,28

Create a simulated bus with simulated devices (family codes 10,12 and 28 in this case). All the responses are predictable (see the web site for the algorithm) and thus useful for automated test scripts.

Specific Options

-p

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 Options

-C --Celsius

-F --Fahrenheit

-K --Kelvin

-R --Rankine

Temperature scale used for data output. Celsius is the default.

Can also be changed within the program at /settings/units/temperature_scale

Format Options

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-code-first form, unlike some other programs and the labelling on iButtons, which are CRC8-first.

-f --format="f[.]i[[.]c]"

Display format for the 1-wire devices. Each device has a 8byte address, consisting of:
f
family code, 1 byte
i
ID number, 6 bytes
c
CRC checksum, 1 byte

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.

Job Control Options

-r --readonly

-w --write

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.

-P --pid-file "filename"

Places the PID -- process ID of owfs into the specified filename. Useful for startup scripts control.

--background | --foreground

Whether the program releases the console and runs in the background after evaluating command line options. background is the default.

--error_print=0|1|2|3

=0
default mixed destination: stderr foreground / syslog background
=1
syslog only
=2
stderr only
=3
/dev/null (quiet mode).

--error_level=0..9

=0
default errors only
=1
connections/disconnections
=2
all high level calls
=3
data summary for each call
=4
details level
>4
debugging chaff

--error_level=9 produces a lot of output

Configuration File

-c file | --configuration file

Name of an owfs (5) configuration file with

more command line parameters

Help Options

See also this man page and the web site http://www.owfs.org

-h --help=[device|cache|program|job|temperature]

Shows basic summary of options.
device
1-wire bus master options
cache
cache and communication size and timing
program
mountpoint or TCP server settings
job
control and debugging options
temperature
Unique ID display format and temperature scale

-V --version

Version of this program and related libraries.

Time Options

These options affect the times that data stays in memory, and the times that the program will wait for network or external device responses. Default values are shown.

--timeout_volatile=15

Seconds until a volatile property expires in the cache. Volatile properties are those (like temperature) that change on their own.

Can be changed within the program at /settings/timeout/volatile

--timeout_stable=300

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 within the program at /settings/timeout/stable

--timeout_directory=60

Seconds until a directory listing expires in the cache. Directory lists are the 1-wire devices found on the bus.

Can be changed within the program at /settings/timeout/directory

--timeout_presence=120

Seconds until the presence and bus location of a 1-wire device expires in the cache.

Can be changed within the program at /settings/timeout/presence

--timeout_serial=5

Seconds until the expected response from the serial port adapter is deemed tardy. Applies to the LINK, DS9097U and DS9097 (passive) adapter.

Can be changed within the program at /settings/timeout/serial

--timeout_usb=5

Seconds until the expected response from the usb port adapter is deemed tardy. Applies to the DS9490.

Can be changed within the program at /settings/timeout/network

--timeout_network=1

Seconds until the expected response from the tcp port adapter is deemed tardy. Includes the LINK-HUB-E and HA7Net

Can be changed within the program at /settings/timeout/network

--timeout_server=5

Seconds until the expected response from the owserver (1) is deemed tardy.

Can be changed within the program at /settings/timeout/server

--timeout_ftp=900

Seconds that an ftp session is kept alive.

Can be changed within the program at /settings/timeout/ftp

--timeout_ha7=60

Seconds that the program will wait for a (tcp) response from the HA7Net adapter.

Can be changed within the program at /settings/timeout/ha7

Persistent Threshold Options

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.

--timeout_persistent_low=600

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

--timeout_persistent_high=3600

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

--clients_persistent_low=10

Maximum number of persistent tcp connections to owserver (1) before connections start getting the more stringent time limitation --timeout_persistent_low

--clients_persistent_high=20

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

Developer Options

--no_dirall

Reject DIRALL messages (requests directory as a single message), forcing client to use older DIR method (each element is an individual message)

--no_get

Reject GET messages (lets owserver determine if READ or DIRALL is appropriate). Client will fall back to older methods.

--no_persistence

Reject persistence in requests. All transactions will have to be new connections.

--pingcrazy

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.

Example

owserver -p 3001 -d /dev/ttyS0 runs owserver on tcp port 3001 and connects to a physical 1-wire bus on a serial port.

See Also

Programs

owfs (1) owhttpd (1) owftpd (1) owserver (1) owdir (1) owread (1) owwrite (1) owpresent (1) owtap (1)

Configuration and testing

owfs (5) owtap (1) owmon (1)

Language bindings

owtcl (3) owperl (3) owcapi (3)

Clocks

DS1427 (3) DS1904(3) DS1994 (3) DS2404 (3) DS2404S (3) DS2415 (3) DS2417 (3)

ID

DS2401 (3) DS2411 (3) DS1990A (3)

Memory

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)

Switches

DS2405 (3) DS2406 (3) DS2408 (3) DS2409 (3) DS2413 (3) DS28EA00 (3)

Temperature

DS1822 (3) DS1825 (3) DS1820 (3) DS18B20 (3) DS18S20 (3) DS1920 (3) DS1921 (3) DS1821 (3) DS28EA00 (3) DS28E04 (3)

Humidity

DS1922 (3)

Voltage

DS2450 (3)

Resistance

DS2890 (3)

Multifunction (current, voltage, temperature)

DS2436 (3) DS2437 (3) DS2438 (3) DS2751 (3) DS2755 (3) DS2756 (3) DS2760 (3) DS2770 (3) DS2780 (3) DS2781 (3) DS2788 (3) DS2784 (3)

Counter

DS2423 (3)

LCD Screen

LCD (3) DS2408 (3)

Crypto

DS1977 (3)

Pressure

DS2406 (3) -- TAI8570

Availability

http://www.owfs.org

Author

Paul Alfille (paul.alfille@gmail.com)


Table of Contents