DHT22 - Probleme Datenübertragung nach FHEM per Script

[Klouse]

Hallo Leute,

leider stehe wieder etwas an und hoffe mir kann jemand von Euch helfen.

Ich habe aus dem Forum nachfolgendes Script:

Code Auswählen Erweitern


#!/bin/bash
cd /opt/lol_dht22
WERTE=$(./loldht 7 | grep "Humidity")
Temp=( $(echo $WERTE | awk '{ print $ 7}'))
Hum=( $(echo $WERTE | awk '{ print $ 3}'))
perl /opt/fhem/fhem.pl 7072 "setreading DHT22 temperature $Temp"
perl /opt/fhem/fhem.pl 7072 "setreading DHT22 humidity $Hum"


Das ausführen dauert zwar leider etwas, da öfters die Meldung "Data not good, skip" erscheint,
funktioniert jedoch aus der Commandline per SSH, ebenso im Hintergrund per ./DHT22.sh&.

Führe ich dieses aus FHEM heraus aus, verhält es sich unterschiedlich:

A: {system("/opt/scripts/./DHT22.sh")}: Hier scheint FHEM abzustürzen, erst nach einem Neustart läuft es dann wieder.

---
B: {system("/opt/scripts/./DHT22.sh&")}:  Hiermit stürzt nicht ab, es folgen aber Meldungen im Log und die Werte werden nicht übertagen:

Code Auswählen Erweitern

Usage: setreading <name> <reading> <value>
where <name> is a single device name, a list separated by komma (,) or a regexp. See the devspec section in the commandref.html for details.

Usage: setreading <name> <reading> <value>
where <name> is a single device name, a list separated by komma (,) or a regexp. See the devspec section in the commandref.html for details.

Ich denke weil das Script hier durchläuft und die Variablen für $Temp und $Hum noch nicht verfügbar sind.

Ziel dahinter wäre die Steuerung der Ausführung per Dummy, um diese ausschalten und auf einen Cron-Job zu verzichten zu können:

Code Auswählen Erweitern


define DHT22_get dummy
attr DHT22_get setlist on off
attr DHT22_get event-on-change-reading .*


define n_DHT22_get notify Flowers_DHT22_get:on \
define DHT22_get_at at +*00:05:00 {system("/opt/scripts/./DHT22.sh&")};; \
attr DHT22_get_at room hidden

define n_DHT22_get_Off notify Flowers_DHT22_get:off \
delete DHT22_at_get


PS.: Gerade getestet per Cron würde es klappen, mich ärgert so etwas nur leider sehr.

Bitte helft mir,

danke!

LG Klaus

[Prof. Dr. Peter Henning]

Falsches Forum.

[Klouse]

Hallo,

ok - selbst verschieben kann ich es wohl nicht.

Schließen und neu eröffnen?


MfG

[crusader]

Wenn man den DHT22 aus der fhem-Anwendung aufrufen will, statt ihn über cron permanent auszulesen, stößt man auf einige Schwierigkeiten:

1. Die vorgeschlagene Lösung A funktioniert nicht, weil das aufgerufenen shell-script unter der gleichen PID wie der fhem-server läuft.  Der Kommunikationsversuch über Port 7072 endet dann in einem Linux-"Selbstgespräch", in dem der connect-Versuch im Wartemodus verbleibt. FHEM bleibt dann bei dem system-Aufruf 'hängen'.

2. Bei der vorgeschlagenen Lösung B ist dieses Problem behoben, weil ein neuer Prozess generiert wird, jedoch fehlt ein 'sudo' vor dem Aufruf des 'loldht'-Treibers, weil dieser mit wiringpi-Befehlen arbeitet.

3. Sollte (bei korrektem Aufruf) der DHT22-Treiber schon beim ersten Versuch einen Wert zurückliefern, so handelt es sich nicht um einen aktuellen Messwert. Der DHT22 liefert nämlich beim Aufruf den abgespeicherten Messwert der zurückliegenden Messung und startet parallel einen neuen Messvorgang. Der Hersteller empfiehlt, den Sensor zweimal aufzurufen und nur den letzten Rückgabewert zu verwenden.

4. 'loldht' ist mit einigen eingebauten Stolpersteinen versehen:

4.a Das Programm verwendet zum Ausmessen der Kommunikations-Pulse einen loop-counter. Das dürfte im Linux-userspace des öfteren daneben gehen. Entsprechend gering ist die Erfolgsrate der Kommunikationsversuche.

4.b Das Programm versucht dieses Problem durch Wiederholversuche zu beheben ('Irgendwann muss es ja mal klappen'). Unglücklicherweise wurde dabei eine Wiederholrate von 1s gewählt, was laut Hersteller zu einem Absturz des Sensors führen kann. Dementsprechend ergeben sich in schöner Regelmäßigkeit Wiederholversuche bis zum eingestellten Maximum.


Wer mit dem loldht arbeiten will, sollte also zumindest die Wiederholrate herabsetzen (min 2s) und den Treiber neu kompilieren.
Wer die entsprechenden System-Ressourcen bereitstellen will, kann stattdessen auch den pigpio-Dämon installieren und die DHT-Treiber von der pigpio-Webseite  http://abyz.co.uk/rpi/pigpio/code/DHT22_py.zip verwenden. Damit klappt es auch ohne Wiederholversuche.

Der erste Leseversuch darf aber in jedem Fall nicht ausgewertet werden.

[Klouse]

Hallo und Wow!

Danke für diese ausführliche Antwort, habe hier nicht mehr damit gerechnet und deswegen nicht nachgesehen.

LG
Klaus

[econ_sl83]

2. Bei der vorgeschlagenen Lösung B ist dieses Problem behoben, weil ein neuer Prozess generiert wird, jedoch fehlt ein 'sudo' vor dem Aufruf des 'loldht'-Treibers, weil dieser mit wiringpi-Befehlen arbeitet.

Darf ich hier noch langer Zeit noch mal ansetzen? Ich erhalte aus diesemThread  https://forum.fhem.de/index.php/topic,25413.msg393941.html#msg393941 genau die gleiche Fehlermeldung...

Code Auswählen Erweitern

Temp=23.5* Humidity=47.7%


Usage: setreading <name> <reading> <value>
where <name> is a single device name, a list separated by komma (,) or a regexp. See the devspec section in the commandref.html for details.


das Anfügen von sudo und perl brauchte nichts.

Hier noch das Skript:

Code Auswählen Erweitern


#!/bin/bash
#cd /home/pi/lol_dht22
WERTE=$(sudo  Adafruit_DHT 22 3 | grep "Humidity")
Hum=$(echo $WERTE|cut -d " " -f3)
Temp=$(echo $WERTE|cut -d " " -f7)
echo $WERTE
echo $Hum
echo $Temp
#/opt/fhem/fhem.pl 7072 "setreading dht2 temperature $Temp"
/opt/fhem/fhem.pl 7072 "setreading dht2 $Hum"


Danke & Grüße