:: fischer-net.de

Die Artikel 1-Wire Software unter Linux - Teil 1 und Teil 2 geben einen Überblick der verschiedenen Möglichkeiten 1-Wire Devices unter Linux zugänglich zu machen. Dies kann z.B. mittels digitemp oder des OWFS 1-Wire Filesystems umgesetzt werden. In den Artikeln Heiz- und Warmwasserkreis überwachen und Zustand von Tür, Tor oder Fenster überwachen habe ich nur zwei von vielen möglichen Anwendungen beschrieben.

Dieser Artikel beschreibt die Integration der 1-Wire Umgebung in die Hausautomations-Software FHEM auf Basis des OWFS 1-Wire Filesystem.

 

Historie

Im Jahr 2008 ermöglichte ich die initiale Anbindung von 1-Wire an FHEM. Damals setzte ich bereits auf das OWFS 1-Wire Filesystem. So entstanden die FHEM Module OFWS und OWTEMP, die seit dem fester Bestandteil der FHEM Distribution sind. Über die Jahre konnten somit Temperaturen erfasst, in FHEM dargestellt und weiterverarbeitet werden.

Da 1-Wire weitaus mehr Möglichkeiten als die Temperaturerfassung bietet, begann ich weitere Module für FHEM zu entwickeln. So entstanden die Module OWCOUNT, OWHUB, OWLCD, OWMULTI sowie OWSWITCH die allerdings nicht veröffentlicht wurden, da mir entweder zeitlich immer wieder etwas dazwischen kam aber auch die Motivation fehlte.

So kam es dazu, das Olaf Droeghorn die Firmware des CUNO um die Möglichkeit erweiterte, ebenfalls auf 1-Wire Devices zugreifen zu können. Die über CUNO angebundenen Temperatursensoren werden über eine HMS Emulation in FHEM eingebunden. Aber man hat auch die Möglichkeit mittels raw Befehlen auf den 1-Wire Bus zuzugreifen. Da der CUNO seitens der Hardware einige Beschränkungen mit sich bringt (z.B. Busspannung), ist die Anbindung an 1-Wire  eingeschränkt.

2012 wurde eine weitere 1-Wire Anbindung an FHEM realisiert. Der Modulautor wählte dabei einen dritten Weg, nämlich über die direkte Anbindung eines Busmaster. Früh versuchte ich alle 3 Wege, also die Anbindung über OWFS, CUNO und Busmaster zu bündeln, so daß letztlich der Anwender nicht vor der "Qual der Wahl" bei der Konfiguration innerhalb von FHEM stünde. So stellte ich dem Modulautor der neuen 1-Wire Module Teile meiner noch nicht veröffentlichten Module zur Verfügung um bereits in einer frühen Entwicklungsphase eine Vereinheitlichung herbei zu führen. Es kam danach aber zu keiner weiteren Zusammenarbeit.

Ende 2012 veröffentlichte Boris Neubert die mittlerweile 4. Variante der 1-Wire Umsetzung in FHEM. Die Module OWServer und OWDevice benötigen ebenso wie meine ursprünglichen Module OWFS und OWTEMP das OWFS 1-Wire Filesystem. Der wohl wesentliche Unterschied zu meinen Modulen ist, daß das Modul OWDevice generisch angelegt ist. Das heißt: Anstatt für jeden 1-Wire Devicetyp ein extra Modul zu schaffen, werde alle Devicetypen im Modul OWDevice gebündelt. Das bringt enorme Vorteile mit sich: der Anwender muss nicht 'zig verschiedene Module definieren aber auch die Pflege des Quelltextes wird damit vereinfacht. Hier geht eindeutig ein Lob an Boris für diesen Ansatz. Warum bin ich damals eigentlich nicht darauf gekommen? ;-)

Anfangs bildete das Modul OWDevice nur einen kleinen Teil der möglichen 1-Wire Device ab, so daß ich mich schnell mit Boris zusammen setzte und von diesem Zeitpunkt an, gemeinsam mit ihm die Module OWServer und OWDevice pflege. Ich erweiterte OWDevice um zahlreiche weitere 1-Wire Devices, integrierte eine Autocreate Funktion (erkannte 1-Wire Devices werden automatisch in FHEM angelegt) und weitere sinnvolle Features. Einige dieser Features werden in diesem Artikel beschrieben.

Mittelfristig werde ich meine Module OWFS und OWTEMP aus der FHEM Distribution herausnehmen, da mit OWServer / OWDevice ein kompletter Ersatz geschaffen wurde. Wer also zum heutigen Zeitpunkt noch "meine" Module verwendet, dem rate ich auf die Module OWServer / OWDevice umzustellen.

 

Voraussetzungen

Wie bereits erwähnt, setzt OWServer / OWDevice auf das OWFS 1-Wire Filesystem auf. Mittlerweilen ist die Software OWFS in den meisten Linux Distributionen über das Paketmanagement installierbar. Fehlt diese Möglichkeit, so beschreibt der Eingangs erwähnte Artikel 1-Wire Software unter Linux - Teil 2 die Installation ohne Paketverwaltung. Für die FHEM Module OWServer / OWDevice wird lediglich die Serverkomponente owserver von OWFS 1-Wire Filesystem benötigt. Sinnvolle Tools aus der OWFS Suite sind owshell und owhttpd. Damit hat man die Möglichkeit auch außerhalb von FHEM z.B. zur Fehlersuche auf den 1-Wire Bus zugreifen zu können. Auf die eigentliche Konfiguration gehe ich an dieser Stelle nicht weiter ein. Hierzu ist bitte der entsprechende Artikel heranzuziehen.

 

Konfiguration innerhalb von FHEM

Das Anlegen der notwendigen Devices in FHEM gestaltet sich recht unspektakulär. Im ersten Schritt wird ein FHEM Device benötigt, das die Schnittstelle zum owserver darstellt und die zentrale Kommunikation übernimmt:

define myOWFS OWServer 192.168.1.8:4304

Dabei stellt myOWFS den frei wählbaren Namen des neuen Devices in FHEM dar. OWServer gibt das zu definierende FHEM Modul an und die IP-Adresse, gefolgt von der Portangabe muss natürlich an die eigene Umgebung angepaßt werden. owserver aus der OWFS Suite "lauscht" per Default auf dem Port 4304. Die IP-Adresse entspricht der Adresse auf dem owserver installiert ist. Läuft der owserver Daemon auf der selben Hardware wie FHEM, so kann hier auch localhost gefolgt von der Portangabe verwendet werden.

OWFS unterstützt auch Installationen mit mehreren Busmastern. Das heißt: Hat man mehrere Busabschnitte mittels eigener Busmaster angebunden, so wird die Information in welchem Bus sich welches 1-Wire Device befindet, auch an FHEM "durchgereicht". Dieses Feature habe ich in OWDevice integriert um z.B. die Position eines Serial iButton identifizieren zu können. Somit kann man z.B. mit einem einzigen iButton seine Garage öffnen aber auch in FHEM erkennen ob dieser am Schlüsselbrett hängt.

Das Anlegen der eigentlichen 1-Wire Devices wird beim Start von FHEM automatisch vorgenommen. Jedes in einem beliebigem 1-Wire Bus gefundenes 1-Wire Device wird im virtuellem Raum "OWDevice" nach folgendem Schema angelegt: MODEL_ADDRESS. Wobei MODEL dem erkannten 1-Wire Device Typ, also z.B. DS18B20, DS2450, usw. entspricht. ADDRESS entspricht der Adresse des gefundenen 1-Wire Device exklusive des Family Codes. Das sieht dann z.B. so aus: DS18B20_000028D70200

Möchte man ein 1-Wire Device manuell anlegen, so gestaltet sich auch dieses recht einfach. Lediglich die Adresse des 1-Wire Devices muss bekannt sein. Der Typ wird automatisch erkannt:

define owtemp OWDevice 28.F14015020000 60

Im obigen Beispiel wurde ein OWDevice Namens owtemp mit der Adresse 28.F14015020000 angelegt. Dem aufmerksamen Leser ist sicherlich noch der zusätzliche Wert 60 aufgefallen: Dieser steht für den Intervall in Sekunden, in dem der Zustand des definierten 1-Wire Device abgefragt werden soll. Sinnvollerweise sollte dieser Wert nicht zu klein, also unter 5 Sekunden, gewählt werden, da jede Anfrage auf dem Bus Zeit kostet. Es ist jedoch ein beliebiger Wert zulässig.

 

Erweiterte Konfiguration 

Seitens des FHEM Moduls findet eine Vorauswahl von sinnvollen Wertabfragen statt. Das heißt, dass z.B. bei einem Temperatursensor vom Typ DS18B20 lediglich der Temperaturwert abgefragt wird. Eine Übersicht der möglichen Parameter ist der Dokumentation von OWFS 1-Wire Filesystem auf der Website configuration man page oder direkt auf der Bash-Konsole des Rechners auf dem owserver installiert ist, durch Eingabe von

man DS18B20

zu entnehmen (sofern die OWFS Dokumentation installiert wurde). So kennt ein DS18B20 neben temperature weitere sogenannte "Special Properties" wie temperature9, temperature10, temperature11, temperature12, fasttemp aber auch "Alarm Limits" wie temphigh und templow.

Jedes 1-Wire Device das eine Alarmierung unterstützt, wird auch in FHEM alarmiert. Die entsprechende Alarmierung muss aktiv durch den Anwender mittels der notify Direktive in FHEM abgefragt werden.

 

Abfragen ändern

Über den optionalen Parameter polls kann je FHEM Device die Voreinstellung der Abfragen geändert werden. Möchte man z.B. eine sehr hohe Temperaturauflösung (12 bit) des Sensors abfragen, so setzt man das Attribut für den oben definierten Sensor wie folgt:

attr owtemp polls temperature12

Sobald der während der Definition vorgegeben Intervall erreicht ist, wird dann an Stelle von temperature das "Special Property" temperature12 abgefragt. Hier sollte man überlegen, welchen Wert man tatsächlich benötigt, denn jede Abfrage kostet auch hier wieder Zeit. Dabei gilt zu berücksichtigen: Ändert man mittels polls die Abfrage, dann "verwaist" der vordefinierte Wert in dem definierten FHEM Device. Im obigen Beispiel wird dann z.B. der Wert für temperature nicht mehr aktualisiert. Möchte man diese "verwaisten" Readings löschen, so dies kann durch einen Aufruf von

deletereading owtemp temperature

vorgenommen werden. Selbstverständlich kann man dem Attribut polls auch mehrere Werte zuweisen.

 

Intervall ändern

In manchen Anwendungsfällen kann es sinnvoll sein, den Abfrageintervall anzupassen. So kann man z.B. den Zustand einer Tür oder eines Fensters (siehe auch Zustand von Tür, Tor oder Fenster überwachen) bei Abwesenheit häufiger abfragen wollen, als wenn man zu Hause ist. Dazu kann während der Laufzeit von FHEM der Intervall eines Devices jederzeit geändert werden:

set owtemp interval 300

Wird FHEM neu gestartet, so gilt der Intervall, der während der ursprünglichen Definition angegeben wurde.

 

Status anpassen und eigene Readings einbinden

Über FHEM interne Attribute können die Readings weiter angepasst werden. So kann man z.B. bei einem 1-Wire Switch Device DS2406 den Status "0" oder "1" mit dem Attribut eventMap nach "open" und "close" ändern.

Weiterhin kann man über das FHEM interne Attribut userReadings eigene Readings für ein Device setzen. So kann man z.B. einem Temperatursensor das Reading humidity hinzufügen, das jedoch von einem anderem Sensor kommt. Über das Attribut stateFormat könnte man dann ebenfalls die FHEM interne Statusanzeige des Temperatursensors anpassen, so daß die Temperatur und die Luftfeuchte (die eigentlich von einem anderen Device kommt) als Status dargestellt wird.

 

Ereignismeldungen und notify

Je nach gewähltem Intervall erzeugt ein definiertes Device auch entsprechend viele Ereignismeldungen. Setzt man z.B. den Intervall eine DS2406 Switch Devices auf 5 Sekunden, wird auch alle 5 Sekunden der Zustand des Devices an FHEM "gemeldet". Auf diese Ereignismeldungen kann mittels der notify Direktive reagiert werden.

Würde man z.B. ein notify erstellen, das den Zustand des DS2406 per eMail (siehe auch Artikel FHEM benachrichtigt bei Event) meldet, dann würde bei jedem Intervall-Durchlauf eine eMail versendet. Bei einem Intervall von 5 Sekunden ist das sicherlich nicht sinnvoll. Hier empfehle ich das Setzen des Attributes event-on-change-reading. Ist dieses Attribut gesetzt, so wird eine Ereignismeldung nur dann generiert, wenn sich der Status auch tatsächlich geändert hat.

 

Umgehung des Zwischenspeichers

owserver arbeitet bei der Abfrage der 1-Wire Devices mit einem intelligenten Zwischenspeicher. Siehe dazu auch die entsprechenden Informationen auf der OWFS Website uncached. Normalerweise arbeitet dieser Zwischenspeicher so genau, das es nicht notwendig ist diesen zu umgehen. Allerdings kann es ggf. notwendig sein, das man die Werte nicht aus dem Zwischenspeicher beziehen will. Hierzu habe ich OWDevice das Attribut uncached "spendiert". Setzt man dieses Attribut über

attr owtemp uncached 1

so wird der Zwischenspeicher von owserver umgangen. Die Werte werden direkt vom entsprechenden 1-Wire Device bezogen. Allerdings kostet diese Abfrage auch mehr Zeit. Siehe dazu auch weiter unten unter "nonblocking" Abfragen.

 

Erweiterte Funktionen von OWServer

Normalerweise muss innerhalb von FHEM neben der oben beschriebenen Definition des OWServer Devices keine weitere Einstellung vorgenommen werden um mit den OWFS 1-Wire Filesystem zu kommunizieren. Dennoch hat das OWServer Modul noch etwas mehr "unter der Haube". So habe ich das Modul um die Möglichkeit erweitert, bestimmte Werte des owserver Daemon abzufragen aber auch setzen zu können.

 

Fehlerstatistiken abfragen und Einstellungen anpassen

Über den Aufruf von

get myOWFS errors

können z.B. diverse Fehlerstatistiken des owserver Daemon angezeigt werden. Diverse Einstellungen wie z.B. timeouts oder units des owserver Daemon können ebenfalls direkt aus FHEM heraus angezeigt oder verändert werden.

 

Anzeige von 1-Wire Devices

Über den Aufruf von

get myOWFS devices

werden alle im owserver gelisteten 1-Wire Devices angezeigt. Ein Beispiel könnte so aussehen:

20.03F30F000000     DS2450 KG.fl.OW.AD.01
28.28609C030000    DS18B20 KG.hz.WDS.T.01
28.2C373C020000    DS18B20 KG.wk.WDS.T.01
28.525715020000    DS18B20 KG.fl.WDS.T.01
28.F9673C020000    DS18B20 KG.k1.WDS.T.01
28.65529C030000    DS18B20 KG.hz.WDS.T.05
28.FD649C030000    DS18B20 KG.hz.WDS.T.02
28.4B909C030000    DS18B20 KG.hz.WDS.T.03
28.4F999C030000    DS18B20 KG.hz.WDS.T.04
12.B61F73000000     DS2406 KG.ga.SEC.SC.01
12.1F2173000000     DS2406 KG.fl.SEC.SC.01
26.168417010000     DS2438 KG.ga.WDS.TH.02
26.455E23010000     DS2438 DG.sp.WDS.TH.01
01.463A73140000     DS2401 KG.sr.OW.ID.01
1D.40500B000000     DS2423 KG.fl.CON.C.02
1D.4EC80D000000     DS2423 KG.fl.CON.C.04
1D.59600B000000     DS2423 KG.fl.CON.C.01
1D.95D10D000000     DS2423 KG.fl.CON.C.03

 

"nonblocking" Abfragen

Im Verlauf des Artikels erwähne ich mehrfach die "Kosten" von Anfragen. Dahinter steht die benötigte Zeit, die eine Abfrage eines Wertes "kostet". Jede Abfrage führt dazu, das FHEM eine Verbindung zum owserver vornehmen muss, dieser dann das 1-Wire Device abfragt und den Wert zurückliefert. Bedingt durch die 1-Wire Architektur kommt es innerhalb von FHEM dann zu kurzzeitigen Stillständen (FHEM wartet auf die Rückmeldung und arbeitet in der Zeit keine weiteren Aufgaben ab), die sich jedoch im Millisekundenbereich bewegen. 

Bei vielen Abfragen kann dieser kurzzeitige "Stillstand" dazu führen, das andere zeitkritische Anwendungen innerhalb von FHEM (z.B. CUL_HM) geblockt sind. Um diesen Zustand zu umgehen, kann das OWServer Device mittles Attribut nonblocking angewiesen werden, die Abfrage in einem Hintergrundprozess auszuführen. Für jede Abfrage wird dann ein "child process" erzeugt, der die jeweilige Abfrage eigenständig im Hintergrund vornimmt. Sobald das Ergebnis vorliegt, wird dieses an den "Hauptprozess" von FHEM zurückgemeldet.

Sicherlich "kostet" auch diese Form der Abfrage Zeit aber sie blockiert FHEM nicht für andere Aufgaben.

 

Ausblick

Die aktuell vorliegen Module OWServer und OWDevice sind nahezu vollständig. Aus meiner Sicht fehlt zur Zeit noch eine Verbrauchsrechnung für Counter. Hierzu wird es sicherlich kurz- bis mittelfristig eine Erweiterung von Boris oder mir geben.

Leider gibt es zur Zeit (Stand Ende Januar 2013) noch ein Problem mit owserver. Sobald der owserver Daemon nicht mehr erreichbar ist, "friert" FHEM komplett ein. Hierzu stehen wir derzeit in Kontakt mit den Entwicklern des OWFS 1-Wire Filesystem. Zwar könnte man dieses Verhalten innerhalb von FHEM umgehen, doch es ist Zielführender das Problem direkt an der Quelle (OWNet.pm) zu beheben.

Abschließend bleibt mir nur noch übrig, mich bei Dr. Boris Neubert für seine initiale Idee mit den FHEM Modulen OWServer / OWDevice zu bedanken. Ohne seine Umsetzung hätte ich wahrscheinlich nicht die Motivation gehabt, weitere Entwicklungsarbeit in entsprechende FHEM 1-Wire Module zu investieren. So kann ich mit gutem Gewissen "meine" Module OWFS und OWTEMP aus der FHEM Distribution zurücknehmen.

Haus-Automatisierung bei conrad.de
Egal ob Stehlampe, Schrankbeleuchtung, Rollladen oder auch Heizlüfter: Mit Conrad.de steuern Sie die unterschiedlichsten Verbraucher effektiv und bequem vom Sessel aus - zu enorm günstigen Preisen! Hier gehts zu den Produkten...

Powered by ...

 

 

reichelt elektronik – Elektronik und PC-Technik