RPI 1Wire: Unterschied zwischen den Versionen
(Erste Version) |
(Migration GPIO4 ergänzt) |
||
Zeile 97: | Zeile 97: | ||
* 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 and DHT11/22 (ungetestet) | * Unterstützung von Robue DS18B20 clones and DHT11/22 (ungetestet) | ||
== 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): | |||
# Im GPIO4 Modul unten auf "Raw definition" klicken. | |||
# Die angezeigten Daten per Klick in das Textfeld und Ctrl-A , Ctrl-C komplett markieren und kopieren. | |||
# Das alte Modul per "Delete this Device" löschen. | |||
# In ein beliebiges anderes Modul gehen und dort mit "Raw definition" den Editor öffnen. | |||
# Mit Ctrl-A, Ctrl-V den alten Inhalt mit den vorher kopierten Daten überschreiben (dem gerade angzeigten Modul passiert dabei nichts!) | |||
# in der ersten "defmod" Zeile '''GPIO4''' gegen '''RPI_1Wire''' austauschen. | |||
# Unten "Execute commands" anklicken. | |||
Somit sollten alle Namen, Einstellungen und Abhängigkeiten komplett in das neue Device übernommen worden sein. | |||
== Definition == | == Definition == |
Version vom 26. Oktober 2021, 21:23 Uhr
RPI_1Wire | |
---|---|
Zweck / Funktion | |
Raspberry Pi 1Wire Interface (GPIO4) | |
Allgemein | |
Typ | Gerätemodul |
Details | |
Dokumentation | EN / DE |
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 ist ermöglicht es Sensoren und Module mit dem Dallas 1-Wire Interface mit 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/DHT12 Sensoren direkt per GPIO ausgelesen werden.
Diese Modul wurde von grundauf neu konzipiert, 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 | Nur lesen, ungetestet |
0x3a | DS2413 | 2 Port Switch | Nur lesen, ungetestet |
0x3b | DS1825 | Temperatur | |
0x42 | DS28EA00 | Temperatur | |
DHT11 | Temperatur und Luftfeuchtigkeit | Nicht über GPIO4 | |
DHT12 | Temperatur und Luftfeuchtigkeit | Nicht über GPIO4 |
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 zusätzlich zum tempOffset
- 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 and DHT11/22 (ungetestet)
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):
- Im GPIO4 Modul unten auf "Raw definition" klicken.
- Die angezeigten Daten per Klick in das Textfeld und Ctrl-A , Ctrl-C komplett markieren und kopieren.
- Das alte Modul per "Delete this Device" löschen.
- In ein beliebiges anderes Modul gehen und dort mit "Raw definition" den Editor öffnen.
- Mit Ctrl-A, Ctrl-V den alten Inhalt mit den vorher kopierten Daten überschreiben (dem gerade angzeigten Modul passiert dabei nichts!)
- in der ersten "defmod" Zeile GPIO4 gegen RPI_1Wire austauschen.
- Unten "Execute commands" anklicken.
Somit sollten alle Namen, Einstellungen und Abhängigkeiten komplett in das neue Device übernommen worden sein.
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 Chips erstellen. Desweiteren kann über den BUSMASTER das therm_bulk_feature für Temperatursensoren genutzt wird. 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
- DHT11|12-<gpio> : Definiert einen DHT Sensor vom Typ 11 oder 12 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.
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 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, dann wird im Reading "precision" der aktuell verwendete Wert angezeigt.
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 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"
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 eine 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 andere 1Wire Devices als w1_therm Temperatursensoren verwendet werden.
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 per fork() in einen eigenen Prozess ausgelagert (mode "nonblocking"). Ein fork() hat aber zur Folge, dass das Betriebssystem eine 1:1 Kopie der 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 das bei sehr vielen Sensoren, die sehr häufig abgefragt werden, der dürfte Speicher z.B. eine 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
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.
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, liefert 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)
percision
Nur bei Temperatursensoren: Die aktuell eingestellte precision wie vom Betriebssystem geliefert
Nur verfügbar mit Linux Kernel 5.10+ (Raspbian Buster und höher)
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
pio1...pio8
Zustand der Schalter von 8-port Switches