OWServer & OWDevice

Aus FHEMWiki


Einleitung

Bei OWServer handelt es sich um eine 1-Wire Server Komponente und bei OWDevice um eine Geräte-Komponente, die die angeschlossenen Module definiert- Die Module benötigen die Serverkomponente von OWFS.


Wichtig:

Die Module sind eine eigenständige Möglichkeit, den 1-Wire Bus anzusteuern und kommen ohne die Module aus, deren Namen aus Großbuchstaben bestehen (wie OWX, OWSWITCH, OWTHERM, etc.). Umgekehrt können die Module OWSWITCH, OWTHERM, etc. auch mit dem Backendmodul OWServer zusammenarbeiten, siehe dazu die commandref der betreffenden Module.


Vorbereitung

Wie oben erwähnt, setzt OWServer/OWDevice auf OWFS auf. Dazu ist eine funktionierende OWFS Installation notwendig. Die Installation ist auf der selben Plattform (Debian-based) möglich oder auch Remote (zBsp Dockstar oder RPi). Eine gute Liste der Standard Devicesauf der Homepage von OWFS einzusehen. Nicht alle Standard Devices sind in OWDevice verfügbar (siehe unten).Wenn OWFS funktioniert kann's weiter gehen...


owfs Pakete installieren

1) entweder sind die Pakete bereits vorpaketiert und man muss nur das Repository noch in /etc/apt/sources.list eintragen

2) oder man muss selber kompilieren (Quelle). Für den RaspberryPi wurde dies schon durchgeführt: owfs_2.8p17-1_all.zip

sudo apt-get install automake autoconf autotools-dev gcc g++ libtool libusb-dev fuse-utils libfuse-dev swig python-dev tcl-dev php5-dev
sudo apt-get install git git-buildpackage dh-make quilt php5-cli
git clone [git://git.debian.org/collab-maint/owfs.git git://git.debian.org/collab-maint/owfs.git] git
git-buildpackage -uc -us
cd ..
sudo dpkg -i ./owserver_2.8p7+cvs20110310-1_i386.deb ./libow-2.8-7_2.8p7+cvs20110310-1_i386.deb ./owfs-common_2.8p7+cvs20110310-1_all.deb
sudo dpkg -i ./owhttpd_2.8p7+cvs20110310-1_i386.deb

diese Pakete werden alle gebaut:

libow-2.8-7_2.8p7+cvs20110310-1_i386.deb   owfs-common_2.8p7+cvs20110310-1_all.deb
libowcapi-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-dbg_2.8p7+cvs20110310-1_i386.deb
libow-dev_2.8p7+cvs20110310-1_i386.deb    owfs-doc_2.8p7+cvs20110310-1_all.deb
libownet-2.8-7_2.8p7+cvs20110310-1_i386.deb  owfs-fuse_2.8p7+cvs20110310-1_i386.deb
libownet-dev_2.8p7+cvs20110310-1_i386.deb   owftpd_2.8p7+cvs20110310-1_i386.deb
libownet-perl_2.8p7+cvs20110310-1_all.deb   owhttpd_2.8p7+cvs20110310-1_i386.deb
libownet-php_2.8p7+cvs20110310-1_all.deb   owserver_2.8p7+cvs20110310-1_i386.deb
libow-perl_2.8p7+cvs20110310-1_i386.deb    ow-shell_2.8p7+cvs20110310-1_i386.deb
libow-php5_2.8p7+cvs20110310-1_i386.deb    python-ow_2.8p7+cvs20110310-1_i386.deb
libow-tcl_2.8p7+cvs20110310-1_i386.deb    python-ownet_2.8p7+cvs20110310-1_all.deb
owfs_2.8p7+cvs20110310-1_all.deb

3) In aktuellen Versionen von Raspbian sind die notwendigen Pakete schon in den konfigurierten Quellen vorhanden. Es reicht ein

sudo apt-get install owserver ow-shell owhttpd owftpd

Unterstütze Geräte

Eine aktuelle Liste der von OWDevice unterstützen Geräte findet man im FHEM-Commandref.


Konfiguration von owserver

Folgendes ist eine beispielhafte Konfiguration für OWFS mit einem am USB-Port angeschlossenen Denkovi-Adapter (Klon von DS9097U).

Es ist praktisch, dem Adapter ein festes Device zuzuordnen. Dazu legt man in /etc/udev/rules.d/ eine Datei 11-onewire.rules mit folgendem Inhalt an:

ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="DAE001nq", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev", SYMLINK+="onewire"

Nach dem Einstöpseln des USB-Kabels vom Adapter wird über die Seriennummer DAE001nq des USB-Wandlers auf dem Adapter das Gerät erkannt und der Symlink /dev/onewire auf das eigentliche USB-Gerät (z.B. /dev/ttyUSB1) erstellt.

Eine Minimalkonfiguration für /etc/owfs.conf ist

server: device = /dev/onewire
http: port = 2121
ftp: port = 2120
server: port = 4304

Es ist sinnvoll, owhttpd installiert und laufen zu haben, um über die URL http://deinRaspberryPi:2121 zu sehen, dass owserver läuft und die Geräte am 1-wire-Bus erkennt.

Konfiguration in FHEM

Als erstes definiert man OWServer. Hiermit wird ein logischer OWServer definiert, auf welchem OWFS installiert ist

define <name> OWServer <protocol>

<protocol> hat das Format <hostname>:<port>.

zBsp:

define myOWServer OWServer 192.168.14.100:4304

oder wenn sich OWFS auf dem gleichen Server befindet wie FHEM:

define myOWServer OWServer localhost:4304

Nach erfolgreichem "define" ist ein Klick auf den "Save" Button notwenig. Wenn nun der Status von myOWServer auf "Initialized" steht, ist der Server verbunden. Um sicher zu sein, dass der OWServer funktioniert, kann eine manuelle Abfrage der Device durchgeführt werden mit:

get myOWServer devices

Danach werden sämtliche angeschlossene Geräte angezeigt, inkl. Busmaster

OWServer Set Befehle

set <name> <value>
value:
timeout/directory
timeout/ftp
timeout/ha7
timeout/network
timeout/presence
timeout/serial
timeout/server
timeout/stable
timeout/uncached
timeout/usb
timeout/volatile
timeout/w1
units/pressure_scale
units/temperature_scale

Weitere Informationen zu den Set Befehlen sind im OWServer Manual zu entnehmen.

OWServer Get Befehle

get <name> <value>
value:
/settings/timeout/directory
/settings/timeout/ftp
/settings/timeout/ha7
/settings/timeout/network
/settings/timeout/presence
/settings/timeout/serial
/settings/timeout/server
/settings/timeout/stable
/settings/timeout/uncached
/settings/timeout/usb
/settings/timeout/volatile
/settings/timeout/w1
/settings/units/pressure_scale
/settings/units/temperature_scale

Zusätzlich stehen die FHEM-internen Befehle "errors" und "devices" zur Verfügung. zBsp:

get <Devicename> errors #listet die Fehler des Device auf
get <Devicename> devices #scan den Server nach Device

Angeschlossene Geräte auslesen

Grundsätzlich werden die am Busmaster von OWFS angeschlossenen 1-Wire Geräte durch aktives autocreate nach einem Neustart (erfordert shutdown restart) selber in FHEM definiert. Der Busmaster (zBsp ein DS9490r) selbst wird ebenfalls eingelesen und angezeigt.

Definition von Geräten

Es ist auch möglich, Geräte manuell anzulegen. Dies erfolgt in folgendem Format:

define <name> OWDevice <address> [<interval>]

zBsp:

define Vorlauftemp OWDevice 28.334F2B040000 60

Wobei der Wert 60 als Abfrageintervall in Sekunden zu verstehen ist.


OWDevice State

Bei Temperaturfühler wie DS18S20 wird das Reading "state" wie folgt ausgegeben:

temperature: 56.1875 alarm: 1

Um die Temperatur wie bei anderen Temperatur-Sensoren (zBsp. CUL_WS) anzuzeigen, hilft das Attribut "stateFormat". Dies kann wie folgt definiert werden:

attr <Devicename> stateFormat T: <wert>

zBsp:

attr Boiler stateFormat T: temperature

alternativ

attr <Devicename> stateFormat {sprintf("%.1f",ReadingsVal("<Devicename>","temperature",0))."°C"}

Zusätzlich rundet das obenstehende Attribut mit "%.1f" die Temperatur auf eine Kommastelle.

Tipps und Tricks

1-wire-Geräte sind häufig generische Geräte, wie Zähler und Spannungsmesser (A/D-Wandler), an denen Sensorik hängt. Die rohen Werte vom 1-wire-Gerät (Zählimpulse, Spannungen) sind dann noch in menschenlesbare Werte zu verwandeln. Hier helfen userReadings, z.B.

attr myEnergyMeter userReadings energy { (ReadingsVal("myEnergyMeter","count.A",0)+AttrVal("myEnergyMeter","myBasis",0))/1250.0;; }

Anwendungsbeispiele

Hier findet man ein Beispiel einer Anbindung zweier Leistungsmesser (aka Stromzähler) mit S0 Ausgang über einen 1-wire-S0-Zähler an FHEM.

Bekannte Probleme

Fhem hängt, wenn OWServer nicht erreichbar ist

Am Anfang gab es mit OWServer das Problem, dass Fhem immer komplett hing, wenn OWServer nicht erreichbar war (siehe z. B. hier am Ende). Das Problem wurde inzwischen dankenswerterweise für den laufenden Betrieb behoben - attr myOWServer nonblocking 1 muss dazu gesetzt werden -, aber zumindest beim Start hängt Fhem nach wie vor, wenn OWServer nicht erreichbar ist.