[Erweiterung] Raspberry: 58_GPIO4 neben 1Wire jetzt auch für DHT11/DHT22

[KölnSolar]

Hallo Ihr Lieben.

Ausgehend von diesem Thema habe ich das 58_GPIO4 erweitert, um zusätzlich zur 1W-Funktionalität auch die Sensorwerte eines DHT11/DHT22 OHNE jegliche Systemerweiterungen/Cron-Jobs.... in FHEM verfügbar zu machen. Ich habe mich für eine Erweiterung entschieden, weil beide Technologien im Standard GPIO4 nutzen u. auch die Technik zum Auslesen der Daten gleich ist.

Meine (vorerst inoffizielle) aktuelle Version des 58_GPIO4 findet Ihr immer hier in diesem Post.

Hintergrund: Sowohl 1W als auch DHT11/DHT22 können an einem GPIO eines raspberry angeschlossen und bei Nutzung des "device-tree" des Betriebssystems über sogenannte overlays aktiviert werden. Dazu ist in der config.txt eine Konfigurationszeile einzutragen(und nach dem save ein reboot zur Aktivierung der Änderung ausgeführt werden):

Für 1w z.B.

Code Auswählen Erweitern

dtoverlay=w1-gpio,gpiopin=4,pullup=off Der gpiopin kann beliebig gewählt werden, da das FHEM-Modul diesbezüglich unabhängig funktioniert.

Für DHT11-/DHT22-Sensoren hingegen wird der Zugriffspfad seitens des OS pinabhängig gebildet. Weil man also in FHEM den GPIO-Pin bekannt machen muss, habe ich mir (in Anlehnung an 1w-Systematik)überlegt, die Definition des Sensors so zu gestalten

Code Auswählen Erweitern

define devicename GPIO4 DHT-gpiopin also z.B. bei Anschluss an GPIO5(GPIO4 ist ja bereits mit 1w belegt):

Code Auswählen Erweitern

define meinDHT GPIO4 DHT-5

In der config.txt des OS muss dazu passend die Zeile

Code Auswählen Erweitern

dtoverlay=dht11,gpiopin=5 eingetragen werden.
(Tipp: wer nur temporär "spielen" möchte, muss NICHT den Eintrag in der config.txt vornehmen u. den Rpi rebooten, sondern es genügt die Eingabe in der Konsole:

Code Auswählen Erweitern

sudo dtoverlay dht11 gpiopin=5Ein reboot ist nicht notwendig. Nach dem nächsten reboot ist die Funktionalität natürlich wieder deaktiviert.)

Mehr ist nicht zu tun, um Temperatur u. Luftfeuchtigkeit zu messen.

Ich selber habe nur mit einem Sensor getestet. Theoretisch müsste es aber auch mit mehreren Sensoren(also auch mehrere GPIO's) funktionieren.
Den im oben verlinkten Thread beschriebenen Lesefehler gibt es leider auch mit meinem Modul. Dazu wird ein Fehlercounter "failures" u. ein reading failreason gefüllt. Zusätzlich ein Logging mit level 2. Wen das stört, der muss verbose auf 1 setzen.
Ich hab ein paar Dinge probiert, um den Fehler zu analysieren, aber auch mehrfaches Lesen u. ein sleep zwischen Open und read führten nicht zum Erfolg. Werden wir wohl mit leben müssen.


Kurze Erläuterung zum physischen Anschluss eines DHTxx: Um Defekte des Rpi zu vermeiden, muss der Pin1 des DHT tunlichst an einen 3,3V-Pin des RPI angeschlossen werden. Pin2 an den selbst gewählten GPIO und Pin4 an einen GND-Pin. Zwischen Pin1 u. Pin2 sollte noch ein 4,7 kOhm-Widerstand eingebaut werden.

Und immer daran denken: Unbedarftheit kann zur Zerstörung des Rpi führen. Also immer mit Ruhe u. Bedacht elektrische Verbindungen herstellen !!!

Grüße Markus

[Adimarantis]

Hallo Markus,

ich bin auch schon länger am überlegen GPIO4 zu überarbeiten.
Hauptproblempunkt den ich sehe, ist dass die Abfrage von DS1820 Sensoren über eine Sekunde blockiert.
In aktuellen Kernels (also wohl seit Buster) gibt es jetzt die Möglichkeit alle angeschlossenen Sensoren gleichzeitig zum Lesen anzutriggern.

Bisher dauerte es ja pro Sensor etwa 900ms

Code Auswählen Erweitern

time cat 28-3c01d07588d2/temperature
21750

real    0m0,974s
user    0m0,000s
sys     0m0,061s


Wenn man jetzt aber vorher folgendes macht:

Code Auswählen Erweitern

time echo trigger >therm_bulk_read

real    0m0,806s
user    0m0,000s
sys     0m0,004s

Was leider auch 800ms dauert. Aber selbst bei vielen Sensoren (ich habe hier aktuell 4) eben nur einmal passieren muss oder man könnte es ggf. auch einfach per shell command in den Hintergrund starten, einen Timer setzen und 1-2 Sekunden später alle Sensoren abfragen.

Dann steht das Ergebnis einmalig sofort bereit:

Code Auswählen Erweitern

time cat 28-3c01d07588d2/temperature
21812

real    0m0,071s
user    0m0,012s
sys     0m0,027s


Leider ist therm_bulk_read per default nur für root schreibbar, was bisher der Hauptgrund war, warum ich das nicht angegangen bin.
Hab mich aber inzwischen schlau gemacht wie man das per udev für bestimmte Gruppen oder evtl. einfach für jeden (ist ja nichts kritisches) beschreibbar machen kann.

Das jetzt einfach mal als Anregung, das dieser Thread der Neuste zum Modul ist.

Zu deiner eigentlichen Erweiterung:
Ich finde ja GPIO4 schon als Modulname grenzwertig (sowas wie 1WIRE fände ich besser). Auch wenn der Anwendungsfall ähnlich ist, würde ich ein Modul, dass eigenen GPIOs braucht von diesem Modul trennen, wo sonst alles klar auf den w1 bus abgestimmt ist.

Jörg

[KölnSolar]

Hi Jörg,

Hauptproblempunkt den ich sehe, ist dass die Abfrage von DS1820 Sensoren über eine Sekunde blockiert.

ist in meiner Version ja per Blocking_Call umgesetzt und daher problemlos. Bei mir ein Dutzend Sensoren. Bei einer schmalbrüstigen CPU lässt sich ggfs. auch die Genauigkeit und damit die Auslesedauer reduzieren.

Ich finde ja GPIO4 schon als Modulname grenzwertig (sowas wie 1WIRE fände ich besser). Auch wenn der Anwendungsfall ähnlich ist, würde ich ein Modul, dass eigenen GPIOs braucht von diesem Modul trennen, wo sonst alles klar auf den w1 bus abgestimmt ist.

Sehe ich nicht so. mit GPIO4 wird verdeutlicht, dass es sich von den anderen 1W-Modulen durch seinen technischen Zugriff abgrenzt. Und bei 1W u. DHT22 wird technisch dasselbe gemacht: ein Systemfile ausgelesen, welche über dtoverlay "gesteuert/konfiguriert" werden. Und denk an die vielen Installationen.

ich bin auch schon länger am überlegen GPIO4 zu überarbeiten

Das Modul hätte es nötig.

Grüße Markus

Edit:

eben nur einmal passieren muss oder man könnte es ggf. auch einfach per shell command in den Hintergrund starten, einen Timer setzen und 1-2 Sekunden später alle Sensoren abfragen.

Auch nur in der Theorie. Ich frage z.B. einen Sensor alle 5s ab, 2 alle 20 und die anderen mit default 60s.

[Adimarantis]

Ich frage mich ja immer welcher Anwendungsfall es benötigt Temperaturen alle 5 Sekunden abzufragen. Dafür sind doch schon allein die Sensoren oft zu träge.
In meiner Heizungs/Solar Automatisierung frage ich sogar nur alle 5 Minuten ab.

Bgzl. BlockingCall: Ich bin kein großer Freund davon hier ständig zu fork()en - das kostet auch einiges an Resourcen.
Wenn schon, dann müsste man das so bauen, das es nur anfangs einen fork gibt, der sich dann um die Sensorenanfrage kümmert und die Ergebnisse an den Hauptprozess überträgt.

Jörg

[Beta-User]

Ich frage mich ja immer welcher Anwendungsfall es benötigt Temperaturen alle 5 Sekunden abzufragen. Dafür sind doch schon allein die Sensoren oft zu träge.

z.B., um die Umwälzpumpe anzuwerfen, falls mal jemand kurzfristig zur falschen Zeit Warmwasser haben will, z.B..
Ich habe sowas auf einem Arduino implementiert . (Genauer: Die Arduinos haben je 2-3 Pins für 1-n Sensoren mit unterschiedlichen Abfrageintervallen je Bus).

Btw.: Der Befehl, die Temperatur zu ermitteln, verpflichtet ja nicht, den Wert hinterher auch abzuholen .

Oder muss man denn bei dem  Pi wirklich (noch) warten, nachdem man den "write to scratchpad"-Befehl abgeschickt hat und kann weiter nicht getrennt den Messauftrag und das Auslesen machen? Klang irgendwie so, als wäre das jetzt endlich "korrekt" im Kernel implementiert...

Was die Namensgebung angeht:
Man muss nicht an jedem historischen Zopf rumschnibbeln , wer sowas sucht, wird es hoffentlich finden, ggf. kann man z.B. auch über das Installer-Modul etwas mehr an durchsuchbarer Doku dazu ermöglichen oder die Kurzbeschreibung aufbohren, das Wiki updaten, ...

[Adimarantis]

z.B., um die Umwälzpumpe anzuwerfen, falls mal jemand kurzfristig zur falschen Zeit Warmwasser haben will, z.B..

Hatte ich früher auch so, aber das war mir zu unzuverlässig. Insbesondere war oft die Leitung (in der Mauer) schon wieder kalt, aber die Temperatur am Sensor noch nicht unter den Threshold gesunken.
Meine Lösung ist jetzt: "Ok Google, Warmwasser an" 
Das kann man dann z.B. auch schon im Wohnzimmer sagen, bevor man sich auf den Weg zur Dusche macht.
Diese Lösung ist jetzt auch einigermassen WAF-tauglich, da sie zuverlässig funktioniert und man eine Rückmeldung bekommt. (Meine Pumpe läuft übrigens nur auf Anforderung)

Oder muss man denn bei dem  Pi wirklich (noch) warten, nachdem man den "write to scratchpad"-Befehl abgeschickt hat und kann weiter nicht getrennt den Messauftrag und das Auslesen machen? Klang irgendwie so, als wäre das jetzt endlich "korrekt" im Kernel implementiert...

Leider ist nach wie vor eine Wartezeit mit dem Auslesen der w1 Sensoren verbunden. Ich hatte einen kurzen Email-Austausch mit Akira, dem Author des Kernel Moduls und er hatte auch nur den Tipp einen extra thread zu machen.
Immerhin triggert das "therm_bulk_read" alle angeschlossenen Sensoren gleichzeitig und man muss nur einmal warten.

Man könnte es natürlich jetzt so machen, dass man einfach kontinuierlich im gefork()ten Prozess einen bulk read triggert - mit timer jede Sekunde (schneller gehts ja eh nicht). Da hier in der Hauptsache gewartet wird, sollte das auch nicht wirklich viel Resourcen verschwenden.
Dann wären immer aktuelle Werte für die einzelnen Sensoren vorhanden und das eigentliche Auslesen der Temperaturen würde immer ohne nennenswerte Verzögerung stattfinden.

Das schöne an der Lösung wäre auch das sie relativ transparent zu implementieren wäre: Einfach checken ob man Schreib-Zugriff auf "therm_bulk_read" hat. Wenn ja parallel Prozess fork()en.
Der Hauptprozess liest die Werte wie gehabt und ist halt entweder schnell - oder eben nicht. Man braucht hier nichtmal gross Prozess-zu-Prozess Kommunikation.
Optimiert wäre natürlich den Trigger synchronisiert im Takt des kleinsten gemeinsamen Teilers zu machen und dann den Hauptprozess zu triggern.

[Beta-User]

Hatte ich früher auch so, aber das war mir zu unzuverlässig. Insbesondere war oft die Leitung (in der Mauer) schon wieder kalt, aber die Temperatur am Sensor noch nicht unter den Threshold gesunken.
Meine Lösung ist jetzt: "Ok Google, Warmwasser an" 

Ja, ist schon in Teilen richtig, das ist auch bei mir nur ein "Hosenträger" . Vor "Porcupine, mach das Warmwasser an" (RHASSPY, offline ) gab's schon lange Taster, und wenn jemand das Badlicht zur "richtigen falschen Zeit" anmacht, kann man daraus ja auch einen Schuh basteln...

Danke jedenfalls für die Erläuterungen bzgl. der Kernel-Änderungen.
Bin da kein Experte, und würde dann eher einen eigenen Script-Job dafür sehen, der das ganze (z.B.) über MQTT (etc. pp...) an FHEM weitergibt.
Eventuell gibt es jetzt ja auch eine Möglichkeit, nicht FHEM komplett zu forken, sondern über "select" (?) zu gehen, wie auch immer das im Detail funktioniert. Mit den älteren Versionen hatte  das KölnSolar aber schon (mit negativem Ergebnis) gecheckt, oder? 

[KölnSolar]

Ich frage mich ja immer welcher Anwendungsfall es benötigt Temperaturen alle 5 Sekunden abzufragen.

Bei mir der Mischer für die Fb-Heizung. Da machste mit

Ok Google

nix. 
Daher halte ich von

einen bulk read

wenig.

Wohl aber anstatt permanent per BlockingCall neu zu Forken, das Ganze in einem Parallelprozess unterzubringen. Aber mangels Zeit gibt es da noch nicht einmal testweise Ansätze.

Leider ist nach wie vor eine Wartezeit mit dem Auslesen der w1 Sensoren verbunden

Was ja an den DS18... liegt. Das lässt sich halt durch Software nicht ändern.

Grüße Markus

[Adimarantis]

Gerade bei einer Fussboden Heizung würde ich denken das die besonders träge reagiert. Ich schalte die bei mir abhängig von Uhrzeit, Fensteröffnung und Raumtemperatur einfach mit einem festen Mischverhältnis ein und aus. Aber du hast da sicher mit rumexperimentiert und deine Gründe für diese super exakte Regelung.
Ich hab jetzt auch nur zwei Fussbodenheizungen - und die heizen auch nicht primär den Raum, sondern sorgen einfach für warme Fliesen.

Was ja an den DS18... liegt. Das lässt sich halt durch Software nicht ändern.

Was die Software ändern kann, ist, das ganze "non-blocking" zu implementieren. Z.B. könnte bereits das Öffnen zum Lesen die Messung starten (aber sofort zurückkehren), so das man dann per Timer 1s später den Wert holen könnte. So ist es aber leider Kernel-seitig nicht implementiert.

Wie gesagt habe ich mir über eine Neuimplementierung auch schon meine Gedanken gemacht (sogar schon mal angefangen, bis ich festgestellt hatte, das es schon neuere Versionen als die aus "contrib" im Forum gibt). Ein Problem ist da bei mir, wie bei dir, dass ich nur eine Sorte Sensor zum Probieren hab. Wobei ich den Counter-Chip extrem cool fände - nur der wird gar nicht mehr hergestellt (der wäre klasse für einen Impuls-Wasserzähler - aktuell hängt der bei mir direkt an einer GPIO, was dauernd Interrupts erzeugt und meinen Rapsi1 gehörig ins schwitzen bringt).

[Beta-User]

Na ja, warum dann nicht das ganze gleich an einen Arduino auslagern...? Kann zählen, (nonblocking) messen, ...

[Maista]

Wobei ich den Counter-Chip extrem cool fände - nur der wird gar nicht mehr hergestellt (der wäre klasse für einen Impuls-Wasserzähler - aktuell hängt der bei mir direkt an einer GPIO, was dauernd Interrupts erzeugt und meinen Rapsi1 gehörig ins schwitzen bringt).

Unter http://www.tm3d.de gibt es es Bausätze oder fertige Module unter anderem für die abgekündigten DS2423.

Ich habe bei mir nach langem Überlegen und die Gefahr den Raspberry zu killen, ein ArduinoMega mit Firmata am laufen (seit 2014). An diesem sind bisher sechs 1W-Ports angeschlossen.

Gruß Gerd

[KölnSolar]

OT

Gerade bei einer Fussboden Heizung würde ich denken das die besonders träge reagiert. Ich schalte die bei mir abhängig von Uhrzeit, Fensteröffnung und Raumtemperatur einfach mit einem festen Mischverhältnis ein und aus. Aber du hast da sicher mit rumexperimentiert und deine Gründe für diese super exakte Regelung.
Ich hab jetzt auch nur zwei Fussbodenheizungen - und die heizen auch nicht primär den Raum, sondern sorgen einfach für warme Fliesen.

Da würden Deine Füße bei 70° Kesseltemperatur ganz schön qualmen.  Ist also nicht super exakt, sondern notwendig, damit der Vorlauf eine gleichmäßige Temp hat.

Was die Software ändern kann, ist, das ganze "non-blocking" zu implementieren. Z.B. könnte bereits das Öffnen zum Lesen die Messung starten (aber sofort zurückkehren), so das man dann per Timer 1s später den Wert holen könnte. So ist es aber leider Kernel-seitig nicht implementiert.

Verstehe Dich nicht mehr. Ist doch in FHEM non-blocking implementiert. 

Ich habe bei mir nach langem Überlegen und die Gefahr den Raspberry zu killen

Das schafft man ja nur, wenn man nicht zwischen 5 u. 3,3 V unterscheidet ...
Grüße Markus

[Adimarantis]

Verstehe Dich nicht mehr. Ist doch in FHEM non-blocking implementiert. 

Wir sind hier jetzt auf die Kernel Ebene abgeschweift - und da hat der Kernel-Modul Programmierer es leider so implementiert, dass jeder Leseversuch auf das Device das Auslesen triggert und das sysread() blockiert bis der Wert verfügbar ist. Das hätte man auch anders lösen können.

Da würden Deine Füße bei 70° Kesseltemperatur ganz schön qualmen.

Ich hab streng genommen keine Fussbodenheizung, sondern eine Fussbodentemperierung. Die läuft immer mit der vollen Vorlauftemperatur. Ich kann nur ein Ventil mehr oder weniger aufdrehen wie bei einem Heizkörper.

[Adimarantis]

Ich mal ein bisschen mit dem w1_therm rumprobiert um Ansätze zu finden wie man ohne BlockingCall auskommt, aber trotzdem FHEM nicht blockiert.

Alle Ansätze benötigen erstmal die Möglichkeit schreibend auf die devices zuzugreifen.
D.h. der Anwender müsste erstmal einen udev Eintrag machen, z.B.
/etc/udev/rules.d/99-w1.rules:

Code Auswählen Erweitern

SUBSYSTEM=="w1*", PROGRAM="/bin/sh -c '\
        chown -R root:gpio /sys/bus/w1;\
        chown -R root:gpio /sys/devices/w1*;\
        find /sys/devices/w1* -type f -perm /u=w -exec chmod g+w {} \; ;\
'"

fhem muss dazu in der Gruppe gpio sein und hat dann Schreibrechte auf die Config.

Variante 1: BUSMASTER übernimmt regelmäßigen bulk read:
Per Timer wird einfach alle x Sekunden folgender Befehl auf der Shell-Ebene ausgeführt - da er in den Hintergrund geschickt wird, kehrt er sofort zurück. Der "echo" Befehl sollte hier deutlich weniger Resourcen verbrauchen als ein fork() des gesamten FHEM systems:

Code Auswählen Erweitern

system("echo trigger >/sys/devices/w1_bus_master1/therm_bulk_read &")

Die einzelnen Devices holen sich ihre Werte ohne BlockingCall - da regelmäßig Conversions getriggert werden (muss man dann halt so einstellen, dass selbst im Worst Case, der Wert nicht zu alt ist), kehrt das Auslesen von "temperature" immer sofort zurück.

Variante 2: conv_time verringern
Ich habe keinen Weg gefunden auf Einzel-Device Ebene eine Conversion erst zu triggern und erst später abzufragen. Ein "Hack" hat bei mir aber funktioniert:
mit

Code Auswählen Erweitern

echo 10 >conv_time
wird die Conversion Time auf 10ms reduziert. Das reicht natürlich nicht um Werte zu bekommen, aber wenn man jetzt die temperature ausliest, triggert das trotzdem eine Conversion (die nach 10ms mit einem alten Wert zurückgehrt). Liest man den Wert aber kurz darauf nochmal, bekommt man den "aktuellen" Wert.
In FHEM hiesse das: Wert lesen, Timer auf 1.5s , Wert nochmal lesen -> und diesen dann übernehmen.

Ich habe jetzt nur DS18B20 zur Verfügung und kann nicht testen für welche anderen W1 devices ähnliche Ansätze funktionieren oder überhaupt nötig sind.

Variante 3 ist natürlich noch ein ständig laufender Parallelprozess (idealerweise macht das der Busmaster zentral, damit dies nicht jede Device machen muss) der die Abfragen übernimmt. Da man nicht davon ausgehen kann, dass jeder Anwender den udev Eintrag macht, wäre diese Option wohl sowieso als Fallback zu implementieren.

Da der BUSMASTER bisher nicht zwingend notwendig ist, muss man wohl sogar eine per Device Variante von (3) zusätzlich vorsehen.

Kommentare und Ideen dazu?

[KölnSolar]

Morjen,
klingt alles sehr kompliziert und systemnah.

Der "echo" Befehl sollte hier deutlich weniger Resourcen verbrauchen als ein fork() des gesamten FHEM systems

Das Forken per Blocking_Call macht doch gar kein Problem.  Wozu der Änderungswille ? 

ein ständig laufender Parallelprozess

Sehe ich durchaus sinnvoll: Der Parallelprozess verarbeitet im Gegensatz zum Blocking_Call sämtliche devices und deren Einstellungen. Die Wichtigste: attr device pollingInterval time. Der Parallelprozess baut eine Queue  ala internaltimer aller devices auf. Diese wird in einer Schleife abgearbeitet: auslesen, timer im Queue-Eintrag ändern, Ergebnis dem FHEM-Prozess zur Verfügung stellen(z.B. per mqtt ? ). Problem wäre aber immer noch das blockierende Verhalten.  Um keinen Verarbeitungsstau bei kleinen Pollingintervallen zu provozieren, müsste auch hier ala BlockingCall geforked werden.