RPI 1Wire: Unterschied zwischen den Versionen

Aus FHEMWiki
(Schreibfehler korrigiert)
K (unnötiges Tag entfernt)
 
(7 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{SEITENTITEL:RPI_1Wire}}
{{Infobox Modul
{{Infobox Modul
|ModPurpose=Raspberry Pi 1Wire Interface (GPIO4)
|ModPurpose=Raspberry Pi 1Wire Interface (GPIO4)
Zeile 7: Zeile 6:
|ModCmdRef=RPI_1Wire
|ModCmdRef=RPI_1Wire
|ModOwner=Adimarantis ({{Link2FU|39402|Forum}}/[[Benutzer Diskussion:Adimarantis|Wiki]])|ModFTopic=123499}}
|ModOwner=Adimarantis ({{Link2FU|39402|Forum}}/[[Benutzer Diskussion:Adimarantis|Wiki]])|ModFTopic=123499}}
 
Das Modul [[RPI_1Wire]] ermöglicht es, Sensoren und Module mit dem Dallas 1-Wire Interface auf dem Raspberry Pi ohne zusätzliche Hardware über dessen GPIO 4 anzusteuern. Es ersetzt das nicht mehr gewartete Modul GPIO4. Mit einem zusätzlichen Perl/C Modul können auch DHT11/DHT22 Sensoren direkt per GPIO ausgelesen werden.
Das Modul [[RPI_1Wire]] ermöglicht esm Sensoren und Module mit dem Dallas 1-Wire Interface auf dem Raspberry Pi ohne zusätzliche Hardware über dessen GPIO 4 anzusteuern. Es ersetzt das nicht mehr gewartete Modul GPIO4. Mit einem zusätzlichen Perl/C Modul können auch DHT11/DHT22 Sensoren direkt per GPIO ausgelesen werden.


Dieses Modul wurde komplett neu konzipiert und geschrieben, ist aber grundsätzlich mit dem Vorbild GPIO4 kompatibel.
Dieses Modul wurde komplett neu konzipiert und geschrieben, ist aber grundsätzlich mit dem Vorbild GPIO4 kompatibel.
Zeile 61: Zeile 59:
|DS2408
|DS2408
|8 Port Switch
|8 Port Switch
|Nur lesen, ungetestet
|
|-
|-
|0x3a
|0x3a
|DS2413
|DS2413
|2 Port Switch
|2 Port Switch
|Nur lesen, ungetestet
|
|-
|-
|0x3b
|0x3b
Zeile 81: Zeile 79:
|DHT11
|DHT11
|Temperatur und Luftfeuchtigkeit
|Temperatur und Luftfeuchtigkeit
|Nicht über GPIO4
|Kein 1-Wire - benötigt eigene GPIO pro Sensor
|-
|-
|
|
|DHT22
|DHT22
|Temperatur und Luftfeuchtigkeit
|Temperatur und Luftfeuchtigkeit
|Nicht über GPIO4
|Kein 1-Wire - benötigt eigene GPIO pro Sensor
|}
|}


Zeile 97: Zeile 95:
* Hilfestellung wie man per udev die resolution und conv_time dauerhaft schreibbar macht
* Hilfestellung wie man per udev die resolution und conv_time dauerhaft schreibbar macht
* Unterstützung von Robue DS18B20 clones (ungetestet) and DHT11/22 (mit extra Perl/C Modul)
* Unterstützung von Robue DS18B20 clones (ungetestet) and DHT11/22 (mit extra Perl/C Modul)
* Unterstützung mehrerer Busmaster


== Umstieg von GPIO4 ==
== Umstieg von GPIO4 ==
Zeile 108: Zeile 107:
# Unten "Execute commands" anklicken.
# Unten "Execute commands" anklicken.
Somit sollten alle Namen, Einstellungen und Abhängigkeiten komplett in das neue Device übernommen worden sein.
Somit sollten alle Namen, Einstellungen und Abhängigkeiten komplett in das neue Device übernommen worden sein.
'''Hinweis''': Das Attribut "model" gibt es nicht mehr (eventueller Fehler kann ignoriert werden), da dies jetzt automatisch als internes Reading befüllt wird.


== Definition ==
== Definition ==
'''define <name> RPI_1Wire BUSMASTER|ff-xxxxxxxxxxxx|DHT11-<gpio>|DHT22-<gpio>'''
'''define <name> RPI_1Wire BUSMASTER|ff-xxxxxxxxxxxx|DHT11-<gpio>|DHT22-<gpio>'''
* BUSMASTER : Verwaltet den 1Wire Bus und kann per Autocreate (beim Start oder über das "scan" Kommando) Devices für alle erkannten 1Wire Chips (also nicht für DHT) erstellen. Desweiteren kann über den BUSMASTER das therm_bulk_feature für Temperatursensoren genutzt werden. Es ist aber nicht zwingend erforderlich einen BUSMASTER zu definieren.
* BUSMASTER : Verwaltet den 1Wire Bus und kann per Autocreate (beim Start oder über das "scan" Kommando) Devices für alle erkannten 1Wire Chips (also nicht für DHT) erstellen. Desweiteren kann über den BUSMASTER das therm_bulk_feature für Temperatursensoren genutzt werden. Es ist aber nicht zwingend erforderlich einen BUSMASTER zu definieren.
* ff-xxxxxxxxxxxx : Definert ein 1Wire Device der Familie "ff". Das Betriebssystem listet alle bekannten Devices im sysfs Verzeichnisbaum unter /sys/device/w1_bus_master - der benötigte String entspricht dem Namen der entsprechenden Unterverzeichnisse.
* ff-xxxxxxxxxxxx : Definert ein 1Wire Device der Familie "ff". Das Betriebssystem listet alle bekannten Devices im sysfs Verzeichnisbaum unter "/sys/bus/w1/devices" - der benötigte String entspricht dem Namen der entsprechenden Unterverzeichnisse.
* DHT11|22-<gpio> : Definiert einen DHT Sensor vom Typ 11 oder 22 an der entsprechenden GPIO. Eine weitere Konfiguration des GPIO Ports ist nicht notwendig. Es wird aber noch das "RPi::DHT" Perl Modul benötigt, welches [https://github.com/bublath/rpi-dht auf GitHub] (zum selbst übersetzen oder als Debian-Package zur Installation mit "apt" für Raspbian "Buster") zu finden ist. Für DHT Sensoren wird pro Sensor eine eigene GPIO (nicht GPIO 4!) benötigt.
* DHT11|22-<gpio> : Definiert einen DHT Sensor vom Typ 11 oder 22 an der entsprechenden GPIO. Eine weitere Konfiguration des GPIO Ports ist nicht notwendig. Es wird aber noch das "RPi::DHT" Perl Modul benötigt, welches [https://github.com/bublath/rpi-dht auf GitHub] (zum selbst übersetzen oder als Debian-Package zur Installation mit "apt" für Raspbian "Buster") zu finden ist. Für DHT Sensoren wird pro Sensor eine eigene GPIO (nicht GPIO 4!) benötigt.
'''Weitere Busmaster:'''
Sofern man einen weiteren 1-Wire Bus benötigt, kann dies in der /boot/config.txt mit "dtoverlay=w1-gpio,gpiopin=xx" definiert werden. Damit der ursprüngliche GPIO-4 1-Wire Bus weiter unter w1_busmaster1 läuft, muss man diese Zeile anscheinend '''vor''' "dtoverlay=w1-gpio" einfügen. Die eigentlichen Devices sind aber transparent unter /sys/bus/w1/devices sichtbar.
Wer ein BUSMASTER Device erzeugen will, um Autocreate oder therm_bulk_read zu verwenden, muss die ID des Busmaster mit Bindestrich an die Defintion anhängen (also ''define xxx RPI_1Wire BUSMASTER-2''). Im internen Reading "devices" werden die zugeordneten Devices aufgelistet, damit man besser sieht was wohin gehört. Default ohne Angabe ist 1.


== Set Befehle ==
== Set Befehle ==
Zeile 142: Zeile 148:
''Nur verfügbar mit Linux Kernel 5.10+ (Raspbian Buster und höher)''
''Nur verfügbar mit Linux Kernel 5.10+ (Raspbian Buster und höher)''


'''Achtung''': Das Kernel Modul w1_therm scheint einen Bug zu haben, der dieses Feature unbrauchbar macht (es tut einfach nichts), wenn weitere 1Wire Devices neben w1_therm Temperatursensoren verwendet werden.
'''Achtung''': Das Kernel Modul w1_therm scheint einen Bug zu haben, der dieses Feature unbrauchbar macht (es tut einfach nichts), wenn weitere 1Wire Devices neben w1_therm Temperatursensoren verwendet werden. Dies kann umgangen werden, indem man eine weitere GPIO als 1Wire Bus definiert, so dass alle Temperatursensoren unter einem Busmaster hängen (siehe "define")
 
=== set clear ===
Setzt den Fehler Zähler ("failures") auf 0
 
=== set pio[a|b|0-7] on|off|on-for-timer|off-for-timer <duration> ===
Für Switch DS2413 (und potentiell DS2406): Schaltet Port a oder b.
 
Für Switch DS2408: Schaltet Port 0 bis 7.
 
Die "duration" definiert bei "on-for-timer" bzw. "off-for-timer" die Dauer in Sekunden, die der Schalter an- bzw- ausgeschaltet werden soll.


== Get Befehle ==
== Get Befehle ==
Zeile 155: Zeile 171:


==== timer ====
==== timer ====
Der Timer Mode macht nur Sinn, wenn man die "conv_time" wie oben beschrieben auf "2" setzt. Dann wird die Abfrage in Abstand von 1.5s per Timer (d.h. FHEM kann in diesen 1.5 Sekunden etwas anderes machen) ausgeführt. Das erste Lesen liefert jetzt noch keinen neuen Wert (da zu kurz abgefragt wurde) und wird daher ignoriert. Es wird dabei aber eine Temperaturmessung getriggert, die nach 1.5s in jedem Fall abgeschlossen ist, so dass das zweite Auslesen den aktuellen Wert erhält und entsprechend ins Reading schreibt. Ein fork() wird dabei komplett vermieden.
Der Timer Mode macht nur Sinn, wenn man die '''"conv_time" wie oben beschrieben auf "2" setzt.''' Dann wird die Abfrage in Abstand von 1.5s per Timer (d.h. FHEM kann in diesen 1.5 Sekunden etwas anderes machen) ausgeführt. Das erste Lesen liefert jetzt noch keinen neuen Wert (da zu kurz abgefragt wurde) und wird daher ignoriert. Es wird dabei aber eine Temperaturmessung getriggert, die nach 1.5s in jedem Fall abgeschlossen ist, so dass das zweite Auslesen den aktuellen Wert erhält und entsprechend ins Reading schreibt. Ein fork() wird dabei komplett vermieden.
 
Um potentiellen Problemen durch unbedarftes Setzen des "timer" mode vorzubeugen, wird dies blockiert, wenn conv_time>9ms ist.


==== blocking ====
==== blocking ====
Der Wert wird ganz normal blockierend mit den oben beschriebenen Konsequenzen ausgelesen. Diese Einstellung kann aber Sinn machen, wenn man im BUSMASTER das "therm_bulk_read" aktiviert und das pollingInterval im BUSMASTER kürzer als im eigentlichen Device wählt. Jetzt steht immer ein fertiger Temperaturwert zur Verfügung der ohne Verzögerung ausgelesen wird. Dieser kann aber ggf. um das pollingInterval veraltet sein. Mit dem default von 60s und der Trägheit von Temperatursensoren, kann dies je nach Anwendungsfall aber durchaus eine akzeptable Lösung sein und sich insbesondere lohnen, wenn man sehr viele Sensoren im Einsatz hat.
Der Wert wird ganz normal blockierend mit den oben beschriebenen Konsequenzen ausgelesen. Diese Einstellung kann aber Sinn machen, wenn man im '''BUSMASTER das "therm_bulk_read" aktiviert''' und das pollingInterval im BUSMASTER kürzer als im eigentlichen Device wählt. Jetzt steht immer ein fertiger Temperaturwert zur Verfügung der ohne Verzögerung ausgelesen wird. Dieser kann aber ggf. um das pollingInterval veraltet sein. Mit dem default von 60s und der Trägheit von Temperatursensoren, kann dies je nach Anwendungsfall aber durchaus eine akzeptable Lösung sein und sich insbesondere lohnen, wenn man sehr viele Sensoren im Einsatz hat.


==== nonblocking ====
==== nonblocking ====
Zeile 164: Zeile 182:


=== pollingInterval ===
=== pollingInterval ===
Definiert in Sekunden in welchen Abständen das Device eine Abfrage durchführt.
Definiert in Sekunden in welchen Abständen das Device eine Abfrage durchführt. Wird pollingInterval auf 0 gesetzt, so finden keine automatisierten Updates mehr statt. Dafür ist dann immer ein "set update" nötig.


Default: 60
Default: 60
Zeile 204: Zeile 222:
''Nur verfügbar mit Linux Kernel 5.10+ (Raspbian Buster und höher)''
''Nur verfügbar mit Linux Kernel 5.10+ (Raspbian Buster und höher)''


=== percision ===
=== precision ===
Nur bei Temperatursensoren: Die aktuell eingestellte precision wie vom Betriebssystem geliefert
Nur bei Temperatursensoren: Die aktuell eingestellte precision wie vom Betriebssystem geliefert


''Nur verfügbar mit Linux Kernel 5.10+ (Raspbian Buster und höher)''
''Nur verfügbar mit Linux Kernel 5.10+ (Raspbian Buster und höher)''
=== duration ===
Liefert die Dauer der letzten durchgeführten Abfrage in Sekunden. Sofern die letzten zwei Abfragen >0.5s waren wird dies in "failreason" gemeldet, sofern mode auf "timer" oder "blocking" steht.


=== temperature ===
=== temperature ===
Zeile 221: Zeile 242:
Zustand der beiden Schalter von 2-port Switches
Zustand der beiden Schalter von 2-port Switches


=== pio1...pio8 ===
=== pio0...pio7 ===
Zustand der Schalter von 8-port Switches
Zustand der Schalter von 8-port Switches
== Einbindung von DHT11/DHT12 Sensoren ==
Auch wenn die DHT Sensoren eigentlich kein 1Wire über GPIO4 sind, wurden sie auf Anregung im Forum in dieses Modul integriert, da es sonst viele Gemeinsamkeiten gibt und viel Code gemeinsam verwendet werden konnte.
Die DHT Sensoren brauchen noch ein zusätzliches Perl Modul, welches die eigentliche Sensor Kommunikation (geschrieben in C, da Echtzeitkritisch) implementiert.
Diese Modul kann entweder direkt von https://github.com/bublath/rpi-dht geclont werden und mit den Befehlen
perl Makefile.PL
make
sudo make install
installiert werden. Dies sollte dann unabhängig von der jeweiligen OS Version funktionieren.
Alterntiv stehen auch fertige Debian packages zur Verfügung:
Für Raspian Buster: https://github.com/bublath/rpi-dht/blob/main/RPi-DHT-perl_1.0-1_armhf.deb
Für Raspian Bulls Eye: https://github.com/bublath/rpi-dht/blob/main/RPi-DHT-perl_2.0-1_armhf.deb
Installation dann mit "dpkg -I <dateiname>"
Außerdem wird noch das Paket "wiringpi" benötigt:
sudo apt install wiringpi
'''Achtung''': Für Raspberry "Bulls Eye" (und neuer) wird nach wie vor nur WiringPi 2.50 zur Verfügung gestellt, welche dort nicht mehr einwandfrei funktioniert. Die Library wird vom Original Author nicht mehr gewartet, es gibt aber ein Community Projekt unter https://github.com/WiringPi/WiringPi welches einige Aktualisierungen vorgenommen hat. Es ist anzuraten diese Version zu installieren.
Der Sensor wird anschliessend in FHEM mit
define <name> RPI_1Wire DHT<11 oder 22>-<gpio> definiert, also z.B.
define myDHT RPI_1Wire DHT11-6
Als Nummerierungsschema wird hier die BCM Nummer verwendet, die man über den "pinout" Befehl erhält. Damit ist die GPIO6 im Beispiel der Pin 31. Wichtig ist hier immer eine eigene GPIO pro Sensor zu verwenden. Eine Anbindung über 1Wire (GPIO4) wie der Modulname suggerieren könnte ist nicht möglich.


== Links ==
== Links ==

Aktuelle Version vom 3. Januar 2024, 12:08 Uhr

RPI_1Wire
Zweck / Funktion
Raspberry Pi 1Wire Interface (GPIO4)
Allgemein
Typ Gerätemodul
Details
Dokumentation EN / DE
Thema
Support (Forum) Einplatinencomputer
Modulname 58_RPI_1Wire.pm
Ersteller Adimarantis (Forum /Wiki)
Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!

Das Modul RPI_1Wire ermöglicht es, Sensoren und Module mit dem Dallas 1-Wire Interface auf dem Raspberry Pi ohne zusätzliche Hardware über dessen GPIO 4 anzusteuern. Es ersetzt das nicht mehr gewartete Modul GPIO4. Mit einem zusätzlichen Perl/C Modul können auch DHT11/DHT22 Sensoren direkt per GPIO ausgelesen werden.

Dieses Modul wurde komplett neu konzipiert und geschrieben, ist aber grundsätzlich mit dem Vorbild GPIO4 kompatibel.

Voraussetzungen

Am Raspberry Pi muss vor der Verwendung das w1-gpio dtoverlay Kernel Modul geladen sein. Mehr dazu, und wie Sensoren/Module richtig angeschlossen werden im Raspberry Pi und 1-Wire Wiki.

Unterstützt oder zumindest erkannt werden aktuell folgende Sensoren/Module:

Familie Name Typ Anmerkung
0x10 DS18S20 Temperatur
0x12 DS2406 2 Port Switch Nur lesen, ungetestet
0x19 DS28E17 I2C Bridge Nur Erkennung, nicht unterstützt
0x1c DS28E04 EEPROM Nur Erkennung, nicht unterstützt
0x1d DS2423 2-fach Zähler
0x26 DS2438 A/D Wandler mit Temperaturmessung
0x28 DS18B20 Temperatur Meistgenutzer Sensor
0x29 DS2408 8 Port Switch
0x3a DS2413 2 Port Switch
0x3b DS1825 Temperatur
0x42 DS28EA00 Temperatur
DHT11 Temperatur und Luftfeuchtigkeit Kein 1-Wire - benötigt eigene GPIO pro Sensor
DHT22 Temperatur und Luftfeuchtigkeit Kein 1-Wire - benötigt eigene GPIO pro Sensor

Funktionen

  • Erkennt alle in der Linux Kernel w1 Dokumentation genannten 1-Wire Chips (unterstützt deswegen aber nicht zwangsläufig auch alle, siehe Tabelle)
  • Anpassung der Temperaturwerte über tempFactor und tempOffset um abweichende Sensoren zu kalibrieren
  • Einstellbare Anzahl Dezimalstellen der Temperaturausgabe
  • Unterstützt die resolution/precision und conv_time zu lesen - und abhängig von den Rechten auch zu setzen
  • Wahlweise blocking, non-blocking und timer-gesteuerter "2-fach-lese" Modus (mehr dazu unten)
  • Hilfestellung wie man per udev die resolution und conv_time dauerhaft schreibbar macht
  • Unterstützung von Robue DS18B20 clones (ungetestet) and DHT11/22 (mit extra Perl/C Modul)
  • Unterstützung mehrerer Busmaster

Umstieg von GPIO4

Für Anwender des bisherigen GPIO4 Moduls kann die Umstellung einfach durch Änderung des Type durchgeführt, werden, da das Modul kompatibel ist. Dies geht leider nicht einfach so, sondern erfordert über die Oberfläche einige Handgriffe (erfahrende User wissen sicher wie das noch einfacher, aber eben auch mit mehr Risiko, geht):

  1. Im GPIO4 Modul unten auf "Raw definition" klicken.
  2. Die angezeigten Daten per Klick in das Textfeld und Ctrl-A , Ctrl-C komplett markieren und kopieren.
  3. Das alte Modul per "Delete this Device" löschen.
  4. In ein beliebiges anderes Modul gehen und dort mit "Raw definition" den Editor öffnen.
  5. Mit Ctrl-A, Ctrl-V den alten Inhalt mit den vorher kopierten Daten überschreiben (dem gerade angezeigten Modul passiert dabei nichts!)
  6. in der ersten "defmod" Zeile GPIO4 gegen RPI_1Wire austauschen.
  7. Unten "Execute commands" anklicken.

Somit sollten alle Namen, Einstellungen und Abhängigkeiten komplett in das neue Device übernommen worden sein.

Hinweis: Das Attribut "model" gibt es nicht mehr (eventueller Fehler kann ignoriert werden), da dies jetzt automatisch als internes Reading befüllt wird.

Definition

define <name> RPI_1Wire BUSMASTER|ff-xxxxxxxxxxxx|DHT11-<gpio>|DHT22-<gpio>

  • BUSMASTER : Verwaltet den 1Wire Bus und kann per Autocreate (beim Start oder über das "scan" Kommando) Devices für alle erkannten 1Wire Chips (also nicht für DHT) erstellen. Desweiteren kann über den BUSMASTER das therm_bulk_feature für Temperatursensoren genutzt werden. Es ist aber nicht zwingend erforderlich einen BUSMASTER zu definieren.
  • ff-xxxxxxxxxxxx : Definert ein 1Wire Device der Familie "ff". Das Betriebssystem listet alle bekannten Devices im sysfs Verzeichnisbaum unter "/sys/bus/w1/devices" - der benötigte String entspricht dem Namen der entsprechenden Unterverzeichnisse.
  • DHT11|22-<gpio> : Definiert einen DHT Sensor vom Typ 11 oder 22 an der entsprechenden GPIO. Eine weitere Konfiguration des GPIO Ports ist nicht notwendig. Es wird aber noch das "RPi::DHT" Perl Modul benötigt, welches auf GitHub (zum selbst übersetzen oder als Debian-Package zur Installation mit "apt" für Raspbian "Buster") zu finden ist. Für DHT Sensoren wird pro Sensor eine eigene GPIO (nicht GPIO 4!) benötigt.

Weitere Busmaster:

Sofern man einen weiteren 1-Wire Bus benötigt, kann dies in der /boot/config.txt mit "dtoverlay=w1-gpio,gpiopin=xx" definiert werden. Damit der ursprüngliche GPIO-4 1-Wire Bus weiter unter w1_busmaster1 läuft, muss man diese Zeile anscheinend vor "dtoverlay=w1-gpio" einfügen. Die eigentlichen Devices sind aber transparent unter /sys/bus/w1/devices sichtbar.

Wer ein BUSMASTER Device erzeugen will, um Autocreate oder therm_bulk_read zu verwenden, muss die ID des Busmaster mit Bindestrich an die Defintion anhängen (also define xxx RPI_1Wire BUSMASTER-2). Im internen Reading "devices" werden die zugeordneten Devices aufgelistet, damit man besser sieht was wohin gehört. Default ohne Angabe ist 1.

Set Befehle

set scan

Nur im BUSMASTER verfügbar. Prüft ob neue 1Wire Devices im sysfs Verzeichnisbaum vorhanden sind und erstellt die FHEM Devices dazu per Autocreate. DHT Sensoren werden auf diese Weise nicht erkannt

set update

Erzwingt ein sofortiges Auslesen. Sofern ein automatisches Auslesen über "pollingInterval" eingestellt ist, startet das Intervall von vorne.

set precision 9|10|11|12

Setzt die Auslesegenauigkeit von Temperaturmodulen. Dieses Kommando ist nur verfügbar, wenn es untersützt wird (abhängig von Sensor und Kernel) und der fhem User Schreibrechte auf den entsprechenden sysfs Eintrag ("resolution") hat. Siehe "udev" wie man permanente Schreibrechte einrichten kann. Durch Änderungen dieser Einstellung wird die conv_time (Zeit die zum Auslesen der Temperatur benötigt wird) auf den jeweiligen Standardwert zurückgesetzt und im entsprechenden Reading angezeigt. Sollte der Sensor den gesetzen Wert nicht unterstützen, zeigt das Reading "precision" trotzdem immer den tatsächlich eingestellten Wert.

Der Wert wird von FHEM gespeichert und bei einem Neustart wieder hergestellt.

Nur verfügbar mit Linux Kernel 5.10+ (Raspbian Buster und höher)

set conv_time <milliseconds>

Setzt die Auslesezeit der Temperatur auf einen neuen Wert. Dieses Kommando ist nur verfügbar, wenn es untersützt wird (abhängig von Sensor und Kernel) und der fhem User Schreibrechte auf den entsprechenden sysfs Eintrag ("conv_time") hat. Siehe "udev" wie man permanente Schreibrechte einrichten kann. Dieser Wert wird bei einer Änderung der "precision" auf den jeweiligen Defaultwert zurückgesetzt. Wird der Wert zu gering gewählt, ist die Messung ggf. noch nicht abgeschlossen und es wird ein alter Wert ausgegeben. Der kleinste Wert ist hierbei 2. Der Wert 1 hat in Tests die conv_time immer fix auf 576 gesetzt, der Wert 0 setzt auf den Default zurück. Wofür man das brauchen kann, siehe unter Attribut "mode"

Der Wert wird von FHEM gespeichert und bei einem Neustart wieder hergestellt.

Nur verfügbar mit Linux Kernel 5.10+ (Raspbian Buster und höher)

set therm_bulk_read on|off

Nur im BUSMASTER verfügbar, sofern die sysfs Datei "therm_bulk_read" durch den User fhem schreibbar ist. Ist dieses Feature eingeschaltet schreibt der BUSMASTER entsprechend des pollingInterval einen Trigger, der eine gleichzeitige Messung aller Temperatursensoren ansteuert. Wofür man das brauchen kann, siehe unter Attribut "mode"

Nur verfügbar mit Linux Kernel 5.10+ (Raspbian Buster und höher)

Achtung: Das Kernel Modul w1_therm scheint einen Bug zu haben, der dieses Feature unbrauchbar macht (es tut einfach nichts), wenn weitere 1Wire Devices neben w1_therm Temperatursensoren verwendet werden. Dies kann umgangen werden, indem man eine weitere GPIO als 1Wire Bus definiert, so dass alle Temperatursensoren unter einem Busmaster hängen (siehe "define")

set clear

Setzt den Fehler Zähler ("failures") auf 0

set pio[a|b|0-7] on|off|on-for-timer|off-for-timer <duration>

Für Switch DS2413 (und potentiell DS2406): Schaltet Port a oder b.

Für Switch DS2408: Schaltet Port 0 bis 7.

Die "duration" definiert bei "on-for-timer" bzw. "off-for-timer" die Dauer in Sekunden, die der Schalter an- bzw- ausgeschaltet werden soll.

Get Befehle

get udev

Nur verfügbar, wenn die Schreibrechte auf precision, conv_time oder therm_bulk_read nicht passen. Zeigt eine Anleitung an, wie man über udev die Rechte so anpasst, dass der w1 sysfs Verzeichnisbaum der Gruppe "gpio" zugeordnet wird und Gruppenschreibrechte auf die entsprechenden Dateien gesetzt werden. Der User fhem muss dazu ggf. noch mit "sudo addgroup fhem gpio" der Gruppe hinzugefügt werden.

Attribute

mode blocking|nonblocking|timer

FHEM ist eine Single-Thread Applikation, d.h. wenn ein Modul, z.B. 1.2 Sekunden auf einen Temperaturwert wartet (übliche Zeit für precision 12) dann ist FHEM in dieser Zeit komplett blockiert. Dies kann unerwünschte Folgen haben, besonders für Anwendungen die ein genaues Timing benötigen (z.B. CUL_HM). Daher werden alle Messungen per Default per BlockingCall über fork() in einen eigenen Prozess ausgelagert (mode "nonblocking"). Ein fork() hat aber zur Folge, dass das Betriebssystem eine 1:1 Kopie des aktuellen FHEM Prozesses anlegt, wozu im schlimmsten Fall auch der ganze Speicher kopiert wird. Dieser Vorgang wird vom Betriebssystem auf die aktuell benötigten Bereiche optimiert. Trotzdem besteht die Gefahr, dass bei sehr vielen Sensoren, die häufig abgefragt werden, der dürftige Speicher z.B. eines Raspberry 1 knapp wird. Daher unterstützt dieses Modul zwei Strategien wie man ohne fork() auskommt, und trotzdem FHEM nicht blockiert

timer

Der Timer Mode macht nur Sinn, wenn man die "conv_time" wie oben beschrieben auf "2" setzt. Dann wird die Abfrage in Abstand von 1.5s per Timer (d.h. FHEM kann in diesen 1.5 Sekunden etwas anderes machen) ausgeführt. Das erste Lesen liefert jetzt noch keinen neuen Wert (da zu kurz abgefragt wurde) und wird daher ignoriert. Es wird dabei aber eine Temperaturmessung getriggert, die nach 1.5s in jedem Fall abgeschlossen ist, so dass das zweite Auslesen den aktuellen Wert erhält und entsprechend ins Reading schreibt. Ein fork() wird dabei komplett vermieden.

Um potentiellen Problemen durch unbedarftes Setzen des "timer" mode vorzubeugen, wird dies blockiert, wenn conv_time>9ms ist.

blocking

Der Wert wird ganz normal blockierend mit den oben beschriebenen Konsequenzen ausgelesen. Diese Einstellung kann aber Sinn machen, wenn man im BUSMASTER das "therm_bulk_read" aktiviert und das pollingInterval im BUSMASTER kürzer als im eigentlichen Device wählt. Jetzt steht immer ein fertiger Temperaturwert zur Verfügung der ohne Verzögerung ausgelesen wird. Dieser kann aber ggf. um das pollingInterval veraltet sein. Mit dem default von 60s und der Trägheit von Temperatursensoren, kann dies je nach Anwendungsfall aber durchaus eine akzeptable Lösung sein und sich insbesondere lohnen, wenn man sehr viele Sensoren im Einsatz hat.

nonblocking

Die Standardeinstellung, welche für alle Anwender die sich keine Gedanken über zusätzliche Optimierungen machen wollen, absolut ok ist.

pollingInterval

Definiert in Sekunden in welchen Abständen das Device eine Abfrage durchführt. Wird pollingInterval auf 0 gesetzt, so finden keine automatisierten Updates mehr statt. Dafür ist dann immer ein "set update" nötig.

Default: 60

tempOffset

Nur für Temperaturmessungen: Offset Wert (Fliesskomma), der zu einer Temperaturmessung hinzuaddiert wird um den Sensor ggf. genauer zu kalibrieren. In Kombination mit "tempFactor" wird erst der Faktor angewendet und dann addiert.

Default: 0

tempFactor

Nur für Temperaturmessungen: Offset Wert (Fliesskomma), mit dem eine Temperaturmessung multipliziert wird um den Sensor ggf. genauer zu kalibrieren. In Kombination mit "tempOffset" wird erst der Faktor angewendet und dann addiert.

Default: 1.0

faultValues

Liste von festen Werten, getrennt durch Leerzeichen, für die Messungen ignoriert werden. Der Wert muss genau (Nachkommastellen) übereinstimmen und der Vergleich findet statt bevor Faktoren, Offsets oder Rundungen angewendet werden.

Default: <leer>

decimals

Nur für Temperaturmessungen: Anzahl der Nachkommastellen, die im "state" Reading (T: x.xx) angezeigt werden. Das Reading "temperature" wird immer vollständig gespeichert.

Default: 3

Readings

failures

Zähler für fehlgeschlagene Versuche Daten vom 1Wire Device zu lesen

failreason

Grund für den zuletzt aufgetretenen Fehler (Zeitstempel beachten):

  • crc: Es konnten zwar Daten gelesen werden, aber eine gebildete Prüfsumme war falsch. Wenn dies öfter vorkommt stimmt evtl. etwas mit der Qualität der Verkabelung nicht
  • no_data: Das Device konnte zwar geöffnet werden, lieferte aber keine Daten
  • open_device: Das Device kann nicht geöffnet werden, wahrscheinlich wurde es seit der Definition entfernt oder taucht aus anderen Gründen nicht mehr im sysfs Verzeichnisbaum auf

conv_time

Nur bei Temperatursensoren: Die aktuell eingestellte conv_time wie vom Betriebssystem geliefert

Nur verfügbar mit Linux Kernel 5.10+ (Raspbian Buster und höher)

precision

Nur bei Temperatursensoren: Die aktuell eingestellte precision wie vom Betriebssystem geliefert

Nur verfügbar mit Linux Kernel 5.10+ (Raspbian Buster und höher)

duration

Liefert die Dauer der letzten durchgeführten Abfrage in Sekunden. Sofern die letzten zwei Abfragen >0.5s waren wird dies in "failreason" gemeldet, sofern mode auf "timer" oder "blocking" steht.

temperature

Temperatur Wert

counter.A/counter.B

Zählerwerte bei Zählern (DS2423)

vad/vdd

Spannungswerte vom DS2438

pioa/piob

Zustand der beiden Schalter von 2-port Switches

pio0...pio7

Zustand der Schalter von 8-port Switches

Einbindung von DHT11/DHT12 Sensoren

Auch wenn die DHT Sensoren eigentlich kein 1Wire über GPIO4 sind, wurden sie auf Anregung im Forum in dieses Modul integriert, da es sonst viele Gemeinsamkeiten gibt und viel Code gemeinsam verwendet werden konnte.

Die DHT Sensoren brauchen noch ein zusätzliches Perl Modul, welches die eigentliche Sensor Kommunikation (geschrieben in C, da Echtzeitkritisch) implementiert.

Diese Modul kann entweder direkt von https://github.com/bublath/rpi-dht geclont werden und mit den Befehlen

perl Makefile.PL
make
sudo make install

installiert werden. Dies sollte dann unabhängig von der jeweiligen OS Version funktionieren.

Alterntiv stehen auch fertige Debian packages zur Verfügung:

Für Raspian Buster: https://github.com/bublath/rpi-dht/blob/main/RPi-DHT-perl_1.0-1_armhf.deb

Für Raspian Bulls Eye: https://github.com/bublath/rpi-dht/blob/main/RPi-DHT-perl_2.0-1_armhf.deb

Installation dann mit "dpkg -I <dateiname>"

Außerdem wird noch das Paket "wiringpi" benötigt:

sudo apt install wiringpi

Achtung: Für Raspberry "Bulls Eye" (und neuer) wird nach wie vor nur WiringPi 2.50 zur Verfügung gestellt, welche dort nicht mehr einwandfrei funktioniert. Die Library wird vom Original Author nicht mehr gewartet, es gibt aber ein Community Projekt unter https://github.com/WiringPi/WiringPi welches einige Aktualisierungen vorgenommen hat. Es ist anzuraten diese Version zu installieren.

Der Sensor wird anschliessend in FHEM mit

define <name> RPI_1Wire DHT<11 oder 22>-<gpio> definiert, also z.B.

define myDHT RPI_1Wire DHT11-6

Als Nummerierungsschema wird hier die BCM Nummer verwendet, die man über den "pinout" Befehl erhält. Damit ist die GPIO6 im Beispiel der Pin 31. Wichtig ist hier immer eine eigene GPIO pro Sensor zu verwenden. Eine Anbindung über 1Wire (GPIO4) wie der Modulname suggerieren könnte ist nicht möglich.

Links