FHEM 1-Wire OWX

Update: Code-Quickie: FHEM und 1-Wire mit OWX-ASYNC

FHEM 1-Wire OWX

Update 01.11.2017

Gerade habe ich im FHEM-Forum gelesen, das die Entwicklung des Moduls OWX_ASYNC eingestellt wurde. Zum Ausgleich wurde im OWX-Modul das Attribut “asynchronous” hinzugefügt.

Ich hatte schon länger mit Performance-Problemen unter FHEM in Verbindung mit 1-Wire zu kämpfen und habe zur Lösung des Problems das FHEM-Modul “OWX_ASYNC” gefunden.

Ich betreibe an meinen beiden FHEM-Systemen “fhem-main” und “fhem-heizung” jeweils einen 1-Wire Busmaster hauptsächlich für Temperatur- und Feuchtesensoren sowie zum Schalten von Relais. Eines ist selber gebaut wie im Bild links zu sehen ist:

Eines ist fertig zusammengebaut (etwas verdeckt, mittiger grüner Anschlussblock) gekauft worden:

FHEM 1-Wire OWX

Beide funktionieren eigentlich problemlos. Eigentlich, denn mit der Zeit habe ich leichte Performance-Schwächen entdecken können, die meine beiden FHEM-Systeme ausgebremst haben. Schlechte Performance nervt mich – siehe dazu den Beitrag “Die Smart-Home Psychologie“.

Um Performance-Probleme in FHEM entdecken zu können verwende ich in der Regel “apptime” sowie das zusätzliche zu installierende Modul “perfmon“. “perfmon” protokolliert in meinem Haupt-LogFile entdeckte Performance Probleme, welche dann mit apptime im Folgenden feiner untersucht werden können.

FHEM 1-Wire OWXFHEM 1-Wire OWX

So konnte ich nun schlussendlich entecken, das jeweils beim eingestellten Abfrageintervall des 1-Wire Busmasters das System kurz für 1-3 Sekunden einfriert.

Nach etwas Suchen sah ich dann, das das FHEM-Modul “OWX”, welches auf den 1-Wire Busmaster zugreift, schuld ist. Kurz im FHEM-Forum nachgeschaut sah ich, das ich nicht der einzige mit diesem Problem war. In einigen Beiträgen wurde auch von einem Modul mit dem Namen “OWX_ASYNC” gesprochen, das ich das auch gleich ausprobierte. Das Modul wird standardmäßig mit FHEM mitgeliefert, was heißt man muss nur die Definition abändern von

define OneWire OWX /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AK05EBV8-if00-port0

 

in

define OneWire OWX_ASYNC /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AK05EBV8-if00-port0

Hier noch meine vollständige Definiton inklusive Attribute:

#########################################################################
## 1-wire Busmaster
#########################################################################
define OneWire OWX_ASYNC /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AK05EBV8-if00-port0
attr OneWire buspower real
attr OneWire dokick 1
attr OneWire group OneWire
attr OneWire interval 60
attr OneWire room Geräte

Erwähnenswert sind hier noch die Attribute “Buspower” sowie “dokick”, dessen Bedeutungen in der comandref nachgelesen werden können. Worin sich die beiden Module letztendlich unterscheiden konnte ich leider weder der commandref noch aus dem FHEM-Wiki entnehmen.

Trotzdem brachte das neue Modul bei mir die Lösung und ich hatte keine Hänger oder Freezes des FHEM-Systems mehr. Allerdings hängte sich nun der 1-Wire Busmaster regelmäßig nach 1-2 Tagen auf. Anscheinend reagierte der Busmaster anders bzw. empfindlicher auf das “OWX_ASYNC”-Modul als wie auf das “OWX”-Modul. Nach etwas Recherche stellte sich heraus, das meine Spannung mit 4,8V etwas zu niedrig und der Auslöser des Problems war. Meine beiden Busmaster werden ja direkt von der USB-Schnittstelle des RaspberryPi versorgt. Also die Plus- und Minus-Leitungen direkt am Meanwell 5V-Netzteil angeklemmt, funktioniert es seither ohne Probleme.

Wer also Probleme, damit meine ich vor allem Performance-Probleme, mit dem normalen “OWX”-Modul hat, sollte mal einen Blick auf das “OWX_ASYNC”-Modul werfen.

Reinhard

Autor von frombeyond.de. Smart-Home-Verrückter.

Nutzt Zuhause FHEM zusammen mit HomeMatic, JeeLink, 1-Wire, Flammtronik / Atmos HV, Buderus KM271, Philips HUE, Xiaomi Yeelight, Alexa, Sonos, FritzBox, Ubiquiti UniFi APs, APC UPS, APC PDU, IPMI. MariaDB, InfluxDB und Grafana zur Auswertung. Als Hardware-Untersatz kommen mehrere RaspberryPis und Supermicro Serverhardware zum Einsatz. Softwareseitig werden hauptsächlich Raspbian, Ubuntu, ESXi und Docker verwendet.