Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)

[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

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

Ein erfolgreicher Lesezugriff führt zu

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)

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

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

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. 

Grüße Markus

[Adimarantis]

Vorschlag Rpi_OW

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.

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 ? 

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]

z.B. fehlt komplett der Teil der erklärt wie man das mit dem dtoverlay einrichtet und wie man es am Besten verdrahtet.

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.

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.

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. 

[Adimarantis]

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. 

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.

[Adimarantis]

Update:
Habe den Namen jetzt auf RPI_1Wire geändert, ein paar Bugs gefixed und die Handhabung von DHT11/DHT22 Sensoren verbessert.
Dazu ist jetzt statt dem Kernelmodul nur ein Perl Modul notwendig, welches auch im ersten Post zum Download zur Verfügung steht und über "apt" installiert werden kann.

[KölnSolar]

Hi Jörg,
bei mir gibt es kein set conv_time Ne Idee warum ?
In der commandref ist noch ein kleiner typo: bei mode fehlt ein b in der letzten Zeile bei blocking
Sonst sehr gut geworden.
Grüße Markus

[Adimarantis]

Sonst sehr gut geworden.

Danke.

bei mir gibt es kein set conv_time Ne Idee warum ?

Bei deinen DS18B20?
Schau mal nach ob das conv_time file im sysfs für den fhem User schreibbar ist - wenn nicht lösche ich es nämlich aus der "set" Liste.
Dafür gibt es ja das "get udev" welches eine Anleitung enthält wie man den Schreibzugriff per udev automatisiert herstellt.

Ich hab inzwischen auch meine beiden FHEM Instanzen per radikal Methode (replace GPIO4 -> RPI_1WIRE im fhem.cfg) umgestellt. Scheint alles sauber zu laufen.

Gruß.
Jörg

[Adimarantis]

Update:
Habe jetzt doch mal das therm_bulk_read feature in den BUSMASTER eingebaut. Möglicherweise Interessant für Leute mit sehr vielen Temperatursensoren (und keinen anderen 1Wire devices, da sonst möglicherweise ein Kernelbug dazu führt dass die Funktion keinen Effekt hat).
Desweiteren habe ich noch zwei kleine Bugs gefunden und die Dokumentation erweitert.

Zur Info: Es finden zu diesem Modul parallel auch Diskussionen in diesem Thread statt: https://forum.fhem.de/index.php/topic,121893.msg1182176.html#new

[KölnSolar]

Trotz der knapp 500 Installationen mag wohl niemand mittesten.  Ich schlage daher vor, dass Du es produktiv schaltest und gleichzeitig die contrib-Version entfernst. Die Legitimation hast Du, da der User fladdy nie auf meine beiden PNs vom 29.3.20 u. 21.2.20 geantwortet hat.

Grüße Markus

[Adimarantis]

Auch mein Gedanke. Werde jetzt noch am Wiki schmieden und dann geht es zügig raus (und GPIO4 wandert in deprecated)

Jörg

[Adimarantis]

Erster Entwurf Wiki steht:
https://wiki.fhem.de/wiki/RPI_1Wire
Gerne mal Querlesen/verbessern.

Das allgemeine 1Wire Wiki https://wiki.fhem.de/wiki/Raspberry_Pi_und_1-Wire müsste auch noch etwas angepasst werden, aber das würde ich erst machen sobald das Modul per update verfügbar ist

[bismosa]

Hallo!

Da meine Temperatursensoren mich mal wieder ärgern mit div. "failures" (ich vermute nach wie vor Timing-Probleme auf meinem mittlerweile doch ausgelastetem System) habe ich mal geschaut, was sich vielleicht im Modul mittlerweile geändert hat.
Hier ist ja richtig viel passiert!  Das macht alles schon einen sehr ausgereiften Eindruck.

Ich finde es toll, dass es dann auch ins Offizielle Update rutscht.  Richtig interessant finde ich auch die Idee mit dem 2fachen Lesemodus. Das könnte bei mir Ressourcen schonen, da ich bereits eine Speicherauslastung von 204MB habe und die jedes Mal kopiert werden müssen. Ich darf auch nur ein Fork auf einmal machen, da sonst mein Speicher (RPi 3B 1GB) ggf. nicht mehr ausreicht.

Da ich mit der bisherigen Variante immer mal wieder Lesefehler habe, die in der Konsole nicht auftreten, habe ich schon drüber nachgedacht einfach dauerhaft per Shell-Skript die Werte an FHEM zu senden.
Dann hat man ebenfalls keine Blocking Calls mehr. 
Wäre es nicht auch eine Möglichkeit ein Script bzw, ein Exec zu starten, dass die Werte dann selbst zurück meldet? Ich mache das melden der Werte in meinen Scripts immer mit:

Code: [Auswählen]

wget -qO/dev/null http://server:8083/fhem?cmd=setreading%20$fhemDevice%20WERT%20NEUERWERT &> /dev/null &
Jetzt werde ich erstmal schauen, wie sich das mit den unterschiedlichen Optionen hier im Modul verhält. 

Hab zum testen mal ein device geändert. Dank Wiki-Eintrag ja problemlos. Es könnte vielleicht noch der Hinweis mit rein, dass das Attribut "model" nicht mehr vorhanden ist und ggf. entfernt werden muss.
Aber das wird einem ja auch von FHEM mitgeteilt.

Eine Frage ist jetzt dennoch offen geblieben. Muss ich die "conv_time" auf 2 ändern, wenn ich mode = timer verwende? Oder wird das intern gelöst?

Beim testen des Moduls ist mir aufgefallen, dass bei einem "set Update" die Seite im Browser immer neu geladen wird. Dadurch sieht man auch nicht, dass ein Reading geupdatet wurde. Ist das wirklich erforderlich? Kann man das nicht beeinflussen, wenn man im "SetFn" "return undef;" zurück gibt?

Trotz der knapp 500 Installationen mag wohl niemand mittesten. 

Das liegt wohl daran (zumindest bei mir) das man erst liest, wenn man Probleme hat. Solange alles läuft...

Gruß
Bismosa

[Adimarantis]

Eine Frage ist jetzt dennoch offen geblieben. Muss ich die "conv_time" auf 2 ändern, wenn ich mode = timer verwende? Oder wird das intern gelöst?

Aktuell nicht. Wäre evtl. eine Überlegung, da der Modus ja sonst echt keinen Sinn macht.

Model wird jetzt ja als internes Reading automatisch befüllt - ist mir gar nicht aufgefallen da nie verwendet, aber danke für den Hinweis, nehm ich ins das Wiki auf.

Das Modul macht unter der Haube wahrscheinlich auch nichts anderes als dein Shell Script - es öffnet die w1_slave Datei und liest den Inhalt aus. Sollte sich daher gleich verhalten.

Jörg

[Adimarantis]

Modul ist (mit ein paar weiteren kleinen Verbesserungen) im SVN eingecheckt und sollte ab morgen per update zur Verfügung stehen

Jörg