OWServer & OWDevice: Unterschied zwischen den Versionen

Version vom 31. Januar 2018, 13:15 Uhr

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

Erste Variante

Die Pakete sind bereits vorpaketiert und man muss nur das Repository noch in /etc/apt/sources.list eintragen

Zweite Variante

Man muss selber kompilieren (Quelle). Version 3.1p0 von owfs lässt sich derzeit für den Raspberry Pi mit USB-Unterstützung nur kompilieren, wenn man einiges in den Make-Files patcht, wie hier beschrieben. Eine ältere, kompilierte Version für den RaspberryPi kann hier heruntergeladen werden: 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 wurden 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

Dritte Variante

In ältere Versionen von Raspbian (Debian wheezy) sind die notwendigen Pakete für Version 2.8p15 schon in den konfigurierten Quellen vorhanden.
In der zukünftigen Version (Debian stretch) sind die Pakete ebenfalls (Version 3.1p1-6) enthalten. Zur Installation reicht jeweils ein

sudo apt-get install owserver ow-shell owhttpd owftpd

Die aktuellen Version von Raspbian (Debian jessie) enthält die Version 2.9p8-6. Diese hat einen Fehler und funktioniert nicht mit Device DS2408. Hier kann alternativ das oben zum Download angegebene Paket owfs_2.8p17-1_all.zip herunter geladen und nach dem Wechsel in das Verzeichnis mit den entpackten Dateien mit

dpkg -i *.deb

installiert werden.

Diese /etc/owfs.conf wurde mit dem Downgrade erfolgreich getestet:

######################## SOURCES ########################
# With this setup, any client (but owserver) uses owserver on the
# local machine...
! server: server = localhost:4304
# ...and owserver uses the real hardware, by default fake devices
# This part must be changed on real installation
#server: FAKE = DS18S20,DS2405
#USB device: DS9490
#server: usb = all
#
#Schnittstelle mit dmesg nach Einstecken ermittelt -> /dev/ttyUSB4
# für Fuchs LinkUSB™ bzw. DS2480B/9097U Emulation
Serial port: DS9097
server: device = /dev/ttyUSB4
#
# owserver tcp address
#server: server = 192.168.10.1:3131
# random simulated device
#server: FAKE = DS18S20,DS2405
######################### OWFS ##########################
#mountpoint = /mnt/1wire
#allow_other
####################### OWHTTPD #########################
http: port = 2121
####################### OWFTPD ##########################
ftp: port = 2120
####################### OWSERVER ########################
server: port = localhost:4304

Vierte Variante

Der in der dritten Variante beschriebene Fehler nach installation aus den offiziellen Quellen kann umgangen werden, indem man /opt/fhem/FHEM/lib/OWNet.pm durch folgende OWNet.pm ersetzt: https://sourceforge.net/p/owfs/code/ci/master/tree/module/ownet/perl5/OWNet/lib/ Dann geht es auch ohne Downgrade (Dank an ak323). Auf der FHEM-Kommandozeile

attr global exclude_from_update lib/OWNet.pm

verhindert das Überschreiben beim FHEM-Update.

Unterstütze Geräte

Eine aktuelle Liste der von OWDevice unterstützen Geräte findet man in der FHEM-commandref/OWDevice.

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. Als erstes ermittelt man dazu den spezifischen Wert ATTRS{serial} mit:

udevadm info -a -p $(udevadm info -q path -n /dev/ttyUSB0) | grep ATTRS{serial}

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

@@ Zeile 10: / Zeile 10: @@
 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.
+Umgekehrt können die Module OWSWITCH, OWTHERM, etc. auch mit dem Backendmodul OWServer zusammenarbeiten, siehe dazu die {{Link2CmdRef}} der betreffenden Module.
@@ Zeile 91: / Zeile 91: @@
 ===Unterstütze Geräte===
-Eine aktuelle Liste der von OWDevice unterstützen Geräte findet man im [http://fhem.de/commandref.html#OWDevice FHEM-Commandref].
+Eine aktuelle Liste der von OWDevice unterstützen Geräte findet man in der FHEM-{{Link2CmdRef|Anker=OWDevice}}.