FHEM - Hardware > Einplatinencomputer

Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)

(1/8) > >>

Adimarantis:
Hallo zusammen,

als fleissiger Nutzer von 1-Wire Temperatursensoren habe ich lange Zeit das alte GPIO4 Modul unter Contrib genutzt, bis ich bemerkt habe, dass im Forum auch neuere Versionen davon "rumgeistern".
Es scheint sich aber niemand gefunden zu haben, der es wieder offiziell maintainen will. Ich möchte hierzu einen Versuch starten.

Dieses Modul basiert zwar auf den mir bekannten GPIO4 Versionen, wurde aber von grundauf neu konzipiert.

Funktionale Unterschiede zum GPIO4 Modul aus dem Forum:
- Erkennt alle in https://www.kernel.org/doc/html/latest/w1/slaves/index.html genannten 1-Wire Chips (unterstützt deswegen aber nicht zwangsläufig auch alle)
- Kann den Zustand der beiden bislang nicht supporteten 2-port switches lesen (ungetestet)
- Führt ein Attribut tempFactor zusätzlich zum tempOffset ein
- 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
- Vollständige(?) englische Inline Dokumentation
- Unterstützung von Robue DS18B20 clones and DHT11/22 (ungetestet)
- und eben vollständig neu geschrieben, womit ich hoffe auch Bugs und Unschönheiten des alten Moduls behoben zu haben

Die Unterschiede zum Modul in contrib zähle ich jetzt nicht auf - in der Summe konnte es nur blockierend messen und kannte nur Temperatursensoren.

Warum heisst das Modul "RPI_1Wire" und nicht "GPIO4"?
- So lässt es sich parallel zu GPIO4 installieren (nicht jeder hat eine Testumgebung) - der Parallelbetrieb sollte problemlos möglich sein (ich kann aber nicht ausschliessen, dass gelegentliche "Kollisionen" bei Messungen mal zu falschen Werten führen)
- Es gibt laut FHEM Statistik 488 Installationen mit 1607 Instanzen des alten GPIO4 Moduls (und nicht jeder hat global->sendStatistics aktiviert). Nur was für Versionen sind das? Contrib? Forum Variante 1-x? Selbst gebastelt? Wenn ich ein GPIO4 über Update zur Verfügung stelle, dann werden alle diese Versionen mit ungeahnten Folgen überschrieben.
- Mein Modul ist zwar weitgehend kompatibel zu GPIO4 - aber eben nicht 100%
- Fügt sich in der Modulübersicht schön zu RPI_GPIO ein

Kurze Info zum mode=timer Feature:
Auf der Suche nach Optionen die Sensorabfrage möglichst resourcenschonend aber eben nicht blockierend zu gestalten, bin ich auf einen kleinen "hack" gekommen.
Indem man die conv_time der Temperatursensoren auf 2ms stellt (1 geht nicht, da setzt er aus unerfindlichen Gründen auf 576ms), erreicht man dass das Auslesen der Temperatur sofort zurückkehrt.
Jetzt ist natürlich noch keine Messung erfolgt, aber es wurde trotzdem eine getriggert. Daher wird im "timer" mode ein interner timer auf 1.5s gesetzt und der Wert erst dann final ausgelesen und schon hat man eine Methode den Sensor ganz ohne fork() performant auszulesen.

Eine weitere Method ist über den w1_bus_master regelmäßig ein "therm_bulk_read" abzustossen. Wenn die einzelnen Sensoren ein kürzeres polling Intervall haben, dann kann man diese auf "blocking" lassen und bekommt immer sofort einen halbwegs aktuellen Wert. Leider musste ich feststellen, das die Kernel-Implementierung einen kleinen Bug hat: Sobald weitere Geräte (außer Temperatursensoren) angeschlossen sind, funktioniert es nicht mehr (jeder Sensorabfrage dauert nach wie vor wie die conv_time). Wer nur Temperatursensoren hat, kann das Feature jedoch getrost einsetzen.

Zur Verwendung von DHT11/DHT22 Sensoren habe ich ein einfaches Perl Modul (mit C-Code Teil) geschrieben, welches entweder unter https://github.com/bublath/rpi-dht ausgecheckt und installiert werden oder für Raspberry unter Buster hänge ich ein kleines Debian Paket an, welches mit "sudo apt install ./name.deb" installiert werden kann (danach FHEM neu starten)

Update 25.10.21: therm_bulk_read hinzugefügt. Dokumenation erweitert. Kleine (eher unerhebliche) Bugfixes.
Update 27.10.21: Veröffentlichung über Update (bzw. svn) daher das Perl Modul hier entfernt.

Gruß,
Jörg

KölnSolar:
Hi Jörg,

der Modulname gefällt mir nicht. Mir geht zu wenig die Einsetzbarkeit(nur auf dem Raspberry) aus dem Namen hervor und grenzt sich nicht genügend deutlich von den anderen OW...-Modulen ab. Vorschlag Rpi_OW  :-\

Bisher nur kurz mit einem DS18B20 getestet: es blockiert scheinbar nicht(sonst hätte mein freezemon mir freezes gemeldet). Das reading temperature wird brav gefüllt. Allerdings erfolgt kein update auf state.

Beim DHT22 gibt es mit verbose=5
--- Zitat ---2021.10.18 17:27:26 4: KlimaKeller1: Poll for dht took 0.026505 s
2021.10.18 17:27:26 1: ERROR: empty name in readingsBeginUpdate
2021.10.18 17:27:26 1: stacktrace:
2021.10.18 17:27:26 1:     main::readingsBeginUpdate           called by ./FHEM/58_OneWire.pm (518)
2021.10.18 17:27:26 1:     main::OneWire_FinishFn              called by (eval 2973345) (1)
2021.10.18 17:27:26 1:     (eval)                              called by fhem.pl (1160)
2021.10.18 17:27:26 1:     main::AnalyzePerlCommand            called by fhem.pl (1189)
2021.10.18 17:27:26 1:     main::AnalyzeCommand                called by fhem.pl (1116)
2021.10.18 17:27:26 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (256)
2021.10.18 17:27:26 1:     main::telnet_Read                   called by fhem.pl (3847)
2021.10.18 17:27:26 1:     main::CallFn                        called by fhem.pl (773)
2021.10.18 17:28:26 5: KlimaKeller1: DeviceUpdate(KlimaKeller1), pollingInterval:60
2021.10.18 17:28:26 5: KlimaKeller1: BlockingCall for KlimaKeller1
2021.10.18 17:28:26 5: KlimaKeller1: Open /sys/devices/platform/dht11@5/iio:device0/in_temp_input
2021.10.18 17:28:26 5: KlimaKeller1: Open /sys/devices/platform/dht11@5/iio:device0/in_humidityrelative_input
2021.10.18 17:28:27 4: KlimaKeller1: No data found in /sys/devices/platform/dht11@5/iio:device0/in_humidityrelative_input
2021.10.18 17:28:27 5: KlimaKeller1: Finish: KlimaKeller1 error=empty_data
--- Ende Zitat ---

Ein erfolgreicher Lesezugriff führt zu
--- Zitat ---2021.10.18 17:31:26 5: KlimaKeller1: DeviceUpdate(KlimaKeller1), pollingInterval:60
2021.10.18 17:31:26 5: KlimaKeller1: BlockingCall for KlimaKeller1
2021.10.18 17:31:26 5: KlimaKeller1: Open /sys/devices/platform/dht11@5/iio:device0/in_temp_input
2021.10.18 17:31:26 5: KlimaKeller1: Read 16700
2021.10.18 17:31:26 5: KlimaKeller1: Open /sys/devices/platform/dht11@5/iio:device0/in_humidityrelative_input
2021.10.18 17:31:26 5: KlimaKeller1: Read 71000
2021.10.18 17:31:26 4: KlimaKeller1: Poll for dht took 0.028801 s
2021.10.18 17:31:26 1: ERROR: empty name in readingsBeginUpdate
2021.10.18 17:31:26 1: stacktrace:
2021.10.18 17:31:26 1:     main::readingsBeginUpdate           called by ./FHEM/58_OneWire.pm (518)
2021.10.18 17:31:26 1:     main::OneWire_FinishFn              called by (eval 2974673) (1)
2021.10.18 17:31:26 1:     (eval)                              called by fhem.pl (1160)
2021.10.18 17:31:26 1:     main::AnalyzePerlCommand            called by fhem.pl (1189)
2021.10.18 17:31:26 1:     main::AnalyzeCommand                called by fhem.pl (1116)
2021.10.18 17:31:26 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (256)
2021.10.18 17:31:26 1:     main::telnet_Read                   called by fhem.pl (3847)
2021.10.18 17:31:26 1:     main::CallFn                        called by fhem.pl (773)

--- Ende Zitat ---
Die ERROR-Meldung ist vermutlich noch vom vorhergehenden Lesefehler ?  :-\  Die "Datenreadings" erfahren deshalb vermutlich auch kein update. "failreason" u. "failcounter" werden befüllt.

Toll finde ich natürlich die commandref.  :-* Hier
--- Zitat ---mode blocking|nonblocking|timer
Reading values from the devices is typically blocking the execution of FHEM. In my tests a typical precision 12 temperature reading blocks for about 1s, a counter read for 0.2s and reading voltages about 0.5s.
While this sounds minimal there are devices that may depend on timing (e.g. CUL_HM) and can be impacted if FHEM is blocked for so long. As a result this module is by default fork()ing a seperate process that does the read operation in parallel to normal FHEM execution. However this operation also comes with cost (see more in "set conv_time" above).
Only applies to temperature measurements: Value that the measured temperature gets multiplied with to calibrate sensors that are off.
In combination with the tempOffset the factor will be applied first, then the offset is added.
Default: 0, valid values: float
--- Ende Zitat ---
sind sicherlich die letzten 3 Zeilen durchs Kopieren zu viel. Was soll mir der letzte Satz in der 4.-Letzten Zeile sagen ? Ist mein Englisch so eingerostet oder zu old-fashioned ?  ;)

Den DHT nehm ich jetzt erst einmal wieder aus dem Test raus. Das können wir dann auch im DHT-Thread weiter diskutieren, da ich vermutlich der einzige bin, der es nutzt.  ;D

Grüße Markus

Adimarantis:

--- Zitat von: KölnSolar am 18 Oktober 2021, 17:50:50 ---Vorschlag Rpi_OW

--- Ende Zitat ---
Was mit RPI_ (wie RPI_GPIO) war mir auch schon in den Sinn gekommen.
"OW" wär mir aber zu nichtssagend. Dann eher RPI_1WIRE.


--- Zitat von: KölnSolar am 18 Oktober 2021, 17:50:50 ---Toll finde ich natürlich die commandref.  :-* Hier sind sicherlich die letzten 3 Zeilen durchs Kopieren zu viel. Was soll mir der letzte Satz in der 4.-Letzten Zeile sagen ? Ist mein Englisch so eingerostet oder zu old-fashioned ?  ;)

--- Ende Zitat ---
Ich glaub ich arbeite zu viel mit Amerikanern. An der Doku muss aber ohnehin noch gefeilt werden. z.B. fehlt komplett der Teil der erklärt wie man das mit dem dtoverlay einrichtet und wie man es am Besten verdrahtet.

Jörg

KölnSolar:

--- Zitat --- z.B. fehlt komplett der Teil der erklärt wie man das mit dem dtoverlay einrichtet und wie man es am Besten verdrahtet.
--- Ende Zitat ---
Das gehört für mich aber auch nicht in eine commandref. Wird sonst zu unübersichtlich. Maximal ein Hinweis-Satz mit Link auf Forumsbeitrag oder Wiki, wo das dann detailliert beschrieben ist.


--- Zitat ---Was mit RPI_ (wie RPI_GPIO) war mir auch schon in den Sinn gekommen.
"OW" wär mir aber zu nichtssagend. Dann eher RPI_1WIRE.
--- Ende Zitat ---
Jooooo. Womit wir dann wieder an dem Punkt wären: das Modul mit oder ohne DHTxx ?  :-\ Bei "mit" käme mir noch RPI_DTO oder RPI_DTOverlay in den Sinn. Aber ich ahne, dass Dir das nicht gefällt.  ;D

Adimarantis:

--- Zitat von: KölnSolar am 18 Oktober 2021, 20:53:42 ---Jooooo. Womit wir dann wieder an dem Punkt wären: das Modul mit oder ohne DHTxx ?  :-\ Bei "mit" käme mir noch RPI_DTO oder RPI_DTOverlay in den Sinn. Aber ich ahne, dass Dir das nicht gefällt.  ;D

--- Ende Zitat ---
Richtig geraten :)
Mit dem DHT (sofern wirs doch zum Laufen kriegen) würde ich jetzt mal nicht so sein. Aber ein autocreate kriegt es wohl eher nicht spendiert - das sind mir dann doch zu viele Sonderlocken, wo ich mich doch eigentlich bemüht habe die "if" Sonderfälle zu reduzieren bzw. zumindest sehr klein und übersichtlich zu halten.

Also bisher gefällt mir RPI_1Wire wirklich am Besten (inkl. der Vorschläge von @Beta-User im anderen Thread - das "look and feel" mit der "1" finde ich auch schöner als z.B. RPI_OneWire.
Aber der Thread ist ja noch jung - vielleicht gibt es noch andere Stimmen dazu.

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln