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

Begonnen von KölnSolar, 02 Juli 2021, 14:18:56

Vorheriges Thema - Nächstes Thema

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.
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 define devicename GPIO4 DHT-gpiopin also z.B. bei Anschluss an GPIO5(GPIO4 ist ja bereits mit 1w belegt): define meinDHT GPIO4 DHT-5

In der config.txt des OS muss dazu passend die Zeile 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: 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

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

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

time cat 28-3c01d07588d2/temperature
21750

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


Wenn man jetzt aber vorher folgendes macht:
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:
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

Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Hi Jörg,
ZitatHauptproblempunkt 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.
ZitatIch 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.

Zitatich bin auch schon länger am überlegen GPIO4 zu überarbeiten
Das Modul hätte es nötig. ;)

Grüße Markus

Edit:
Zitateben 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.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Beta-User

Zitat von: Adimarantis am 11 September 2021, 21:10:50
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, ...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Adimarantis

Zitat von: Beta-User am 11 September 2021, 21:50:51
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)

Zitat von: Beta-User
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.



Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Beta-User

Zitat von: Adimarantis am 11 September 2021, 23:09:44
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" ;D . Vor "Porcupine, mach das Warmwasser an" (RHASSPY, offline :P ) 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? 
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

KölnSolar

ZitatIch 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
ZitatOk Google
nix.  ;D
Daher halte ich von
Zitateinen 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. :o :'(

ZitatLeider 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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

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.

ZitatWas 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).
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Beta-User

Na ja, warum dann nicht das ganze gleich an einen Arduino auslagern...? Kann zählen, (nonblocking) messen, ...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Maista

Zitat von: Adimarantis am 12 September 2021, 09:58:34
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
ZitatGerade 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.  ;D Ist also nicht super exakt, sondern notwendig, damit der Vorlauf eine gleichmäßige Temp hat.

ZitatWas 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.  ???

ZitatIch 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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

ZitatVerstehe 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.
ZitatDa 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.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

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:
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:
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
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?


Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Morjen,
klingt alles sehr kompliziert und systemnah.
ZitatDer "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 ?  :-\

Zitatein 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.  ???
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Das Forken per Blocking_Call macht doch gar kein Problem.  ??? Wozu der Änderungswille ?  :-\
Da bin ich vielleicht zu sehr um die Performance besorgt.

Um meine instinktive Abneigung gegen das fork()en von FHEM zu be/widerlegen habe ich mal Messungen gemacht.
Szenario ist
a) Blockingcall aufrufen der nur einen konstanten String zurückgibt. Gemessen wird vor Aufruf BlockingCall() bis Ende Finish Funktion.
b) system() Aufruf mit echo in den Hintergrund

System                   |  BlockingCall  | system("echo &")
Raspi400 (Testsystem)    |   31 ms        |  27 ms
Raspi4 (Prodsystem)      |   78 ms        |  27 ms
Raspi1 (Prodsystem)      |  400-500 ms    |  88 ms


Wie zu erwarten gibt es einen Unterschied zwischen dem fast blanken Testsystem zu meiner Produktiven Installation mit HMCCU und vielen anderen Device (fork() muss mehr Speicher kopieren)
Allerdings bewegt sich das auf den relativ performanten 4er Raspis sicher in einem Bereich den man vernachlässigen kann.

Meine GPIO4 Anwendungen laufen allerdings auf zwei Rapsi1 (historische Gründe und aufgrund des 26-Pol Kabels nicht so leicht upgradebar).
Dort sind die Unterschiede schon etwas deutlicher, wobei Blockingcall im Vergleich zur alten, blockierenden GPIO4 Version immer noch Vorteile bringt.
Die eigentliche Initiierung des BlockingCall (also die Zeit die FHEM wirklich blockiert ist) liegt aber auch nur bei ca. 50ms, also ganz klar akzeptabel und sogar schneller als meine "echo" Idee.

Das würde jetzt erstmal dafür sprechen, die aktuelle Lösung beizubehalten.

Wenn man jetzt aber einen Blick auf den Speicherverbrauch wirft, dann braucht FHEM bei mir je nach Installation schon mal 100MB virtual (70 MB RES) memory.
Jeder fork() braucht erstmal identisch nochmal soviel Speicher (optimiert da das OS irgendwas?)
Ich habe auf einer Instanz 10 GPIO4 Sensoren. Wenn die in höherer Frequenz abgefragt werden, dürfte das 512MB Raspis ziemlich ans Limit bringen.
Hier ist dann ein permanenter fork() pro Device sogar ganz klar ein no-go, sondern es geht nur die Variante mit dem BUSMASTER.
Dadurch, dass dieser dann üblicherweise gleich beim FHEM Neustart erstellt wird, dürfte der noch recht klein sein.

Mein Fazit:
Die one-size-fits all Lösung gibt es nicht sondern hängt ab von
- Systemperformance
- Systemspeicher
- Abfragefrequenz
- Zugriffrechten /sys/devices/w1

Je nachdem passt
1. Einfacher Blocking Call per device (wie jetzt)
2. Permanenter Blocking Call im BUSMASTER
    a) mit Einzelabfrage
    b) mit bulk read
3. Komplett ohne blocking call mit "conv_time" hack (offen: mit welchen Devices geht das?)

Nachdem 2) recht aufwändig zu implementieren ist (sync mit den ganzen slaves), tendiere ich dazu 3) als alternative für die Temperatursensoren anzubieten (eben für Systeme mit vielen Sensoren und wenig Speicher) - ganz vielleicht noch 2b) - dann auch mit Option den BlockingCall in den Devices optional zu deaktivieren (ohne sync)
Standard bleibt 1) für Anwender die sich keine Gedanken machen wollen und keine Speicher oder Performanceprobleme haben.





Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Du baust Dir theoretische Hürden auf. (Übrigens sehr OT  >:( )

Mein Rpi3 langweilt sich zu Tode. Neben einem umfangreichen FHEM läuft nur noch pihole fürs gesamte Inet , zigbee2mqtt, "altes Alexa" dauerhaft. 1W-Konstellation hab ich bereits ausführlich beschrieben. freezes > 0,3 s habe ich so gut wie nie, und wenn, ist es nachvollziehbar anderen Modulen geschuldet.

Verbessern geht immer. Aber das sollten wir dann außerhalb dieses Threads im Development-Bereich diskutieren. Da finden sich auch eher Experten mit dem ein oder anderen Tipp.  ;)
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Dann wieder on topic:

Ich habe mit einen DHT22 besorgt um das mal live zu testen (umschreiben vom GPIO4 Modul ist fast fertig).
Das dtoverlay einzurichten klappt auch - alle Einträge im sysfs wie erwartet.
Nur wenn ich versuche in_temp_input (einfach in der shell mit "cat") auszulesen gibt es immer einen timeout.

Hab schon mit verschiedenen GPIO Nummerierungen rumprobiert, aber ohne Erfolg. Die Nummer ist BCM, oder?
Sensor ist wie beschrieben mit 3.3V, GPIO und GND am Raspberry angeschlossen (mit 4.7K zwischen 3.3V und GPIO).
Noch Ideen was falsch laufen kann?

Was mir noch aufgefallen ist: Die DHT@GPIO Nummerierung im sysfs ist hexadezimal. Könnte bei höheren GPIO Nummern zur Verwirrung führen.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Hi Jörg,
ZitatNoch Ideen was falsch laufen kann?
Nicht wirklich.  :-[ Hast Du es mehrfach probiert ? Ich habs gerade mal mit cat /sys/devices/platform/dht11@5/iio:device0/in_temp_inputversucht. Ergebnis: geht/geht_nicht  ::)

Beim Anschluss muss ja alles bei Dir passen, wenn
Zitatalle Einträge im sysfs wie erwartet

Das "Ding" ist irgendwie unsauber programmiert. Ich hab mit dem Modul bei 13 Tagen uptime im Schnitt 1.200 Lesefehler/Tag, also fast 50%.  :o :'(
Aber für ne reine Datenaufzeichnung(vs. Steuerung) ist es ausreichend.
Grüße Markus

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Hallo Markus,

ich habs schon in Endlosschleife probiert aber ich bekomme nie Werte.
Kann man irgendwie sehen ob der DHT überhaupt erkannt wurde? Meine Verzeichnisse sehen so aus:
pi@raspi400:/sys/devices/platform/dht11@5 $ ls
driver           iio:device1  of_node  subsystem
driver_override  modalias     power    uevent
pi@raspi400:/sys/devices/platform/dht11@5 $ ls iio\:device1/
dev                        in_temp_input  of_node  subsystem
in_humidityrelative_input  name           power    uevent
pi@raspi400:/sys/devices/platform/dht11@5 $

Und das Unabhängig davon ob tatsächlich ein Sensor dran hängt kommt immer
pi@raspi400:/sys/devices/platform/dht11@5/iio:device1 $ cat in_temp_input
cat: in_temp_input: Die Wartezeit für die Verbindung ist abgelaufen

Ich hab sogar schon mal aus lauter Paranoia über falsche GPIO das dtoverlay für ALLE GPIO deklariert und dann überall in_temp_out (mehrmals) ausgelesen. Nichts :(

Entweder mein Chip ist kaputt oder ich übersehe noch irgendwas.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Hi Jörg,
der Unterschied, der mir auffällt ist, dass es bei Dir device1 und nicht device0 ist. Du bist da wahrscheinlich jetzt tiefer in der Materie als ich(Halbwertzeit von Wissen  :'(), ob das eine Bedeutung hat ? Aber die in_*_input files sind ja da.  ???

Berechtigung ? Mach mal ein
ls -l /sys/devices/platform/dht11@5/iio:device1
Ich nutz ja gerne Win_SCP. Hast Du das und kannst evtl. die Dateien dort sehen und öffnen ?

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Hi Markus,

die Device1 kam rein, da ich testweise zwei dtoverlays definiert hatte - und da zählt er wohl diese Nummer eindeutig - aber nicht deterministisch - hoch (was es jetzt für ein Modul auch nicht einfacher macht).
Rechte schauen gut als - für alle lesbar und teilweise für root schreibbar (z.B. in_temp_input  - warum auch immer - hab mal versucht was reinzuschreiben und bekam trotzdem einen Fehler).

Ich glaub ich gebs auf und schicke den Sensor wieder zurück (zum Glück Amazon :) ).

Vielleicht kannst du ja den DHT Teil meines Moduls testen - habs jetzt zum Test veröffentlicht:
https://forum.fhem.de/index.php/topic,123499.0.html

Gruß,
Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Beta-User

Hi, habe die Ankündigung gesehen und will ausdrücklich nicht mittesten - hätte aber ein paar Anmerkungen:

- "OneWire" finde ich als Modulnamen ziemlich irreführend - es gibt bereits diverse Module für OneWire(-IO). Vielleicht eher "OW_GPIO" (oder sogar "OW_Pi-GPIO") ? Dann sortiert sich das in commandref-modular zu den anderen hin: https://fhem.de/commandref_modular.html

- Wenn du schon nicht "einpackst", wäre es zumindest hilfreich, nicht grade POSIX (pauschal alles, ohne qw) und Data::Dumper nach main zu importieren. Ersteres ist (zu Rudis Leidwesen) sowieso schon da, letzteres als Speicherloch suspekt...

(Ansonsten sieht perlcritic - abgesehen von den "üblichen Verdächtigen" - ganz ok aus, Respekt!)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Adimarantis

Danke für die Hinweise :)
Beide "use"'s waren Überbleibsel und werden nicht benötigt. Gleich mal rausgenommen und im Post geupdated, dass sonst keiner meckert :)

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Beta-User

Thx.

(Es würde aber nicht schaden, die von perlcritic auf Level 3 (neben den üblichen Verdächtigen für die anderen Stufen) angemeckerten Punkte mal anzusehen ;) ).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Adimarantis

Done :)
perlcritic 58_OneWire.pm
58_OneWire.pm source OK


perlcritic kannte ich gar nicht. Wieder was gelernt :)
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Beta-User

...das ging ja schnell...

Bzgl. der "üblichen Verdächtigen" finde ich es ja lobenswert, dass du die Prototypes rausgehauen hast. Du solltest dann aber auf andere Weise sicherstellen, dass du ausreichend Variablen übergeben bekommst (oder sonst Defaultwerte hinterlegst).

Beispiel wäre in https://forum.fhem.de/index.php/topic,122708.0.html zu finden (braucht dann aber "use carp;", wenn man das so macht):
sub z2t_send_weekprofile {
  my $name       = shift // carp q[No device name provided!]              && return;
  my $wp_name    = shift // carp q[No weekprofile device name provided!]  && return;
  my $wp_profile = shift // carp q[No weekprofile profile name provided!] && return;
.

Falls du das seltsam findest: "//" bedeutet Perl-defined-or-Operator.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Adimarantis

Zitat von: Beta-User am 18 Oktober 2021, 17:46:55
Bzgl. der "üblichen Verdächtigen" finde ich es ja lobenswert, dass du die Prototypes rausgehauen hast. Du solltest dann aber auf andere Weise sicherstellen, dass du ausreichend Variablen übergeben bekommst (oder sonst Defaultwerte hinterlegst).
Innerhalb des Moduls habe ich das ja selbst in der Hand. Und ich kann nicht gerade sagen, dass die Prototypen wirklich immer passend waren.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Adimarantis

Hi Markus,

Zitat2021.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)

Das ist seltsam. Bei mir funktioniert das (den Fall "keine Daten" kann ich ja auch ohne echte Device testen). Ich schick den DHT22 jetzt zurück und hab mir einen Fünferpack DHT11 bestellt - da wird ja hoffentlich irgendwas funktionieren - außerdem kann man da den "mehr als ein DHT" Fall testen.
Kannst du mal ein list von dem Device machen -  das hört sich ja so an als würde der Devicename im $hash der readingsBeginUpdate übergeben wird fehlen.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Beta-User

Zitat von: Adimarantis am 18 Oktober 2021, 19:24:56
Innerhalb des Moduls habe ich das ja selbst in der Hand. Und ich kann nicht gerade sagen, dass die Prototypen wirklich immer passend waren.
letzteres: qed

ersteres: "Der Teufel ist ein Eichhörnchen", und das gilt vor allem dann, wenn man meint, in main bleiben zu müssen. Der eigentliche Vorteil ist der: man sieht gleich, was erwartet wird und hat dann auch eine Doku, wie es eigentlich gedacht ist. Bei dem kleinen Modulchen vielleicht nicht oberwichtig, aber Fehler reißen FHEM halt uU. auch gleich mit einer "undefined"-Meldung in den Abgrund, und später hat man vielleicht nicht mehr daran gedacht, welche/wie viele Parameter erforderlich sind...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

KölnSolar

Hi Jörg,

habs nochmal neu angelegt. Diesmal war der erste Zugriff eigentlich erfolgreich und trotzdem
Zitat2021.10.18 20:03:11 1: Define init_done: KlimaKeller1 OneWire DHT-5
2021.10.18 20:03:12 5: KlimaKeller1: Finish: KlimaKeller1 error=empty_data
2021.10.18 20:04:11 5: KlimaKeller1: DeviceUpdate(KlimaKeller1), pollingInterval:60
2021.10.18 20:04:11 5: KlimaKeller1: BlockingCall for KlimaKeller1
2021.10.18 20:04:11 5: KlimaKeller1: Open /sys/devices/platform/dht11@5/iio:device0/in_temp_input
2021.10.18 20:04:11 5: KlimaKeller1: Open /sys/devices/platform/dht11@5/iio:device0/in_humidityrelative_input
2021.10.18 20:04:12 4: KlimaKeller1: No data found in /sys/devices/platform/dht11@5/iio:device0/in_humidityrelative_input
2021.10.18 20:04:13 5: KlimaKeller1: Finish: KlimaKeller1 error=empty_data
2021.10.18 20:05:11 5: KlimaKeller1: DeviceUpdate(KlimaKeller1), pollingInterval:60
2021.10.18 20:05:11 5: KlimaKeller1: BlockingCall for KlimaKeller1
2021.10.18 20:05:11 5: KlimaKeller1: Open /sys/devices/platform/dht11@5/iio:device0/in_temp_input
2021.10.18 20:05:11 5: KlimaKeller1: Read 16700
2021.10.18 20:05:11 5: KlimaKeller1: Open /sys/devices/platform/dht11@5/iio:device0/in_humidityrelative_input
2021.10.18 20:05:11 5: KlimaKeller1: Read 71500
2021.10.18 20:05:11 4: KlimaKeller1: Poll for dht took 0.027922 s
2021.10.18 20:05:11 1: ERROR: empty name in readingsBeginUpdate
2021.10.18 20:05:11 1: stacktrace:
2021.10.18 20:05:11 1:     main::readingsBeginUpdate           called by ./FHEM/58_OneWire.pm (518)
2021.10.18 20:05:11 1:     main::OneWire_FinishFn              called by (eval 3004870) (1)
2021.10.18 20:05:11 1:     (eval)                              called by fhem.pl (1160)
2021.10.18 20:05:11 1:     main::AnalyzePerlCommand            called by fhem.pl (1189)
2021.10.18 20:05:11 1:     main::AnalyzeCommand                called by fhem.pl (1116)
2021.10.18 20:05:11 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (256)
2021.10.18 20:05:11 1:     main::telnet_Read                   called by fhem.pl (3847)
2021.10.18 20:05:11 1:     main::CallFn                        called by fhem.pl (773)
Das list dazu Internals:
   CFGFN     
   DEF        DHT-5
   FUUID      616db6df-f33f-49d8-ce91-6a9f061791e992a9
   NAME       KlimaKeller1
   NOTIFYDEV  global
   NR         634216
   NTFY_ORDER 50-KlimaKeller1
   STATE      T: 16.7 H: 70.9
   TYPE       OneWire
   family     DHT
   id         5
   model      DHT-5
   .attreocr:
     humidity
     temperature
     battery
   .attrminint:
     humidity:600
     temperature:600
   .userReadings:
     HASH(0x5a55728)
   READINGS:
     2021-10-18 20:26:13   Luftentfeuchter 0
     2021-10-18 17:12:56   dewpoint        11.4
     2021-10-18 20:26:13   failreason      empty_data
     2021-10-18 20:26:13   failures        15485
     2021-10-18 17:17:56   humidity        70.9
     2021-10-18 17:17:56   state           T: 16.7 H: 70.9
     2021-10-18 17:17:56   temperature     16.7
   getList:
     udev       noArg
   helper:
     write     
     RUNNING_PID:
       abortArg   
       abortFn   
       bc_pid     614465
       finishFn   OneWire_FinishFn
       fn         OneWire_Poll
       pid        DEAD:10479
       terminated 1
       timeout   
       arg:
   setList:
     update     noArg
Attributes:
   event-min-interval humidity:600,temperature:600
   event-on-change-reading humidity,temperature,battery
   room       Keller,Klima
   userReadings Luftentfeuchter { if (ReadingsVal($name,"dewpoint",0) > ReadingsVal("Feinstaub","dewpoint",0)) {1} else {0}}
   verbose    5


Grüße Markus

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Hi Markus,

Ich hab jetzt mal hardcoded erfolgreiche Daten bei mir simuliert und prompt zwei Fehler gefunden - die schauen allerdings anders als bei dir aus.
Habs im anderen Thread geupdated. Vielleicht hängt das ja doch zusammen.

Wie erstellt du das Device? Schaut so aus als wäre das irgendwie von deiner GPIO4 Instanz gecloned.
Wenn der Fehler immer noch besteht, könntest du auf jeden Fall mal ein "set update" machen. Da wird viel initalisiert - vielleicht hilfts (und gibt mit einen Hinweis)
Sonst wäre auch interessant ob es nach einem "shutdown restart" immer noch Probleme macht.

Gruß,
Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Hi Jörg,

ZitatWie erstellt du das Device? Schaut so aus als wäre das irgendwie von deiner GPIO4 Instanz gecloned.
Na klar. Ich bin ein fauler Mensch.  ;D Sorry für die Verwirrung.

Ich probier die neue Version....

Grüße Markus

Edit: Leider keine Veränderung mit der neuen Version. Auch nicht beim DS18B20-device bzgl. state. shutdown/restart muss ich überlegen, weil ich gerade auch zum leakage Thema teste.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

#33
Jetzt wirds klar: Hab gerade nochmal geschaut welchen "Weg" der Code wohl bei deinem Clone geht und hab was gefunden, das eher auf deine Fehlermeldung passt.
Ich spiel gleich nochmal ein update ein.

Edit: Gerade dein Edit gesehen - das mit dem "state" muss eigentlich jetzt passen - da hab ich schon vor paar Stunden eine Änderung zu gemacht.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Beta-User

Kurzer Senf noch bzgl. des Modulnamens: RPI_.* finde ich gut, dann sortiert sich das zu den anderen GPIO-Spielereien für Pi (obwohl es wohl auch auf anderen Plattformen gehen dürfte, die diese kernel-Modifikation verstehen). Ab da wäre ich persönlich relativ leidenschaftslos, und würde nur darüber nachdenken, beide (alle drei?) Schreibweisen entweder im Modulnamen oder der Kurzbeschreibung unterzubringen (damit man es beim suchen in der Webseite findet).

"Modular" wird wohl demnächst default, btw..

Just my (unmaßgebliche) 2ct.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

KölnSolar

Zitatdas mit dem "state" muss eigentlich jetzt passen - da hab ich schon vor paar Stunden eine Änderung zu gemacht
Erwischt. Ich hab einen Fehler beim Einspielen der neuen Version gemacht gehabt.  :o

Mit der aktuellen läuft der DHT u. state beim DS18B20 ist auch OK. Ich lass beide Sensoren nun dauerhaft laufen.

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Beta-User

Zitat von: Adimarantis am 19 Oktober 2021, 07:43:25
Was meinst du damit genau?
Zitat von: rudolfkoenig am 15 September 2021, 17:36:44
Ich wuerde gerne ein FHEM 6.1 Paket erstellen,  [...]
P.S.: Ich habe vor die Voreinstellung von "attr global commandref" von full auf modular zu aendern.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Adimarantis

So, jetzt sind meine DHT11 angekommen.
Erst dachte ich schon da funzt wieder was nicht, aber die müssen wohl erst mal "warm laufen". Erst nach etwa 5 Minuten kamen andere Ergebnisse als "0".
Entweder war mein DHT22 wirklich kaputt oder der geht mit dem DHT11 Kernel Treiber einfach doch nicht, denn ich habe den DHT11 einfach an die selbe Stelle ins Breadboard gesteckt und gut.

Ein kleiner Bug ist noch drin. Wenn nur einer der beiden Werte klappt, dann gibt es einen Stacktrace wegen undefined value, stört aber nur wenn man ins logfile schaut. Lohnt erstmal nicht deswegen ein Update einzuspielen.
Die wichtigere Frage ist ob man auf einfache Art und Weise diese device id rauskriegen kann (iio:device0). Wenn mehr als ein DHT11 dran hängen, dann steht hier ja eine laufende Nummer drin (ich vermute mal nach der Reihenfolge der Initialisierung, was schlimmstenfalls nichtmal immer gleich ist).
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Zitatder geht mit dem DHT11 Kernel Treiber einfach doch nicht
doch, doch. Ich hab den 22er laufen.

ZitatDie wichtigere Frage ist ob man auf einfache Art und Weise diese device id rauskriegen kann (iio:device0).
Finde ich nicht wichtig. Wer wird schon auf die Idee kommen, mehr als 1 drahtgebundene Klimasensor am Rpi zu betreiben. Für "nur Temperatur" wäre DS18.... die bessere Wahl.

Bin mal gespannt, was bei Dir der Fehlercounter macht.  ;D (Ein Grund warum kaum jemand mehr als 1 Sensor betreiben wird)

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Also irgendwie ist da noch der Wurm drin. Ich denke ich habe eine Methode gefunden, fast immer Werte zu bekommen. Ich mach einfach bis zu 3 retries wenn ich keine Daten bekomme - erst temp dann humidity. Normal brauche ich einen retry auf temp und humidity geht eigentlich immer.
Allerdings: Die Werte werden fast nie aktualisiert - d.h. ich bekomme immer das selbe. Wenn ich in dmesg schaue dann sehe ich:
[  584.106816] dht11 dht11@5: Don't know how to decode data: 71 0 21 5
[  587.036381] dht11 dht11@5: Don't know how to decode data: 71 0 21 6
[  592.052977] dht11 dht11@5: Don't know how to decode data: 71 0 21 6
[  597.067236] dht11 dht11@5: Don't know how to decode data: 71 0 21 6
[  602.083851] dht11 dht11@5: Don't know how to decode data: 71 0 21 5
[  607.779939] dht11 dht11@5: Don't know how to decode data: 71 0 21 5
[  612.792483] dht11 dht11@5: Don't know how to decode data: 71 0 21 5
[  617.812519] dht11 dht11@5: Don't know how to decode data: 70 0 21 5

Für mich schaut das wie Humidity 71.0 und Temp 21.6 aus und die Werte ändern sich auch - nur kommt der Wert nicht in den in_temp_input/in_humidityrelative files an. Da bekomme ich immer den selben (alten) Wert oder sogar 0.

Steht bei dir was in dmesg?
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Adimarantis

Der Kernel-Treiber ist einfach Schrott. Vielleicht kommt der auch mit meinem Raspi 4(00) nicht zurecht (welchen hast du im Einsatz?)
Wenn ich die Python Library von adafruit oder ein perl Modul von cpan nehme, funktioniert es recht zuverlässig.

Vielleicht macht des Sinn auf das Perl Modul zu gehen. Magst du mal
sudo cpan install RPi::DHT11
installieren und mit folgendem Perl Programm testen ob das auch mit dem DHT12 geht:
use RPi::DHT11;

my $pin = 5;
my $env = RPi::DHT11->new($pin);

my $temp     = $env->temp;
my $humidity = $env->humidity;

print "T: $temp  H: $humidity\n"
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Kurzfassung, weil mein ausführliches Geschriebsel wieder "verschwunden" ist.

Ist bei mir auch alles so. Ich hab aber in meiner lokalen Version noch etwas zusätzliches error handling eingebaut.

Zitatinstallieren und mit folgendem Perl Programm testen ob das auch mit dem DHT12 geht:
Mach ich. Gibt's das auch per apt ?
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Hi Markus,

apt gibt es leider keins.
Ich hab gestern noch ein wenig mit dem Teil rumgespielt und es hat ein Riesenproblem: Der liest so lange Werte bis er was hat - d.h. wenn du z.B. die falsche GPIO konfigurierst, dann geht er in eine Endlosschleife. Sowas kann ich natürlich nicht in einem Modul verwenden. Der Code ist aber so übersichtlich, dass man den ganz einfach umschreiben kann - hat halt einen Teil in "C".
Und irgendwie unterschlagen bei mir alle Lösungen (der Kernel Treiber wie auch diese RPi::DHT11 Teil) die Nachkommastellen bei der Temperatur - ist das bei dir auch so?
Dabei ist es ganz einfach zu fixen (meine umgebaute RPi:DHT11 Variante kann das jetzt).

Ist die Frage wie gross das Interesse hier ist. Ich denke ich könnte auch ein apt bauen und eben eine Version mit timeout und Nachkommastellen zur Verfügung stellen.
Du siehst schon, ich hab Spass an sowas rumzubasteln :)

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Hi Jörg,
ZitatIst die Frage wie gross das Interesse hier ist.
Sicherlich gering, wie man an den Beiträgen schon sieht. Ob es über uns beide hinaus einen weiteren Anwender gibt ?  ;D

Zitatdie Nachkommastellen bei der Temperatur - ist das bei dir auch so?
Nein. Sowohl mit meinem GPIO4, als auch Deinem OneWire(es werden zwar 3 angezeigt, die sind aber immer 0) habe ich eine Nachkommastelle. Das liegt daher eher(glaub ich) an dem Unterschied DHT11/DHT22. Der 11er hat ja eine geringere Genauigkeit.
Gerade hab ich tatsächlich einen Wert 0 bei humidity mit OneWire beobachtet.

ZitatDu siehst schon, ich hab Spass an sowas rumzubasteln :)
Ja. Bei mir hört der Ehrgeiz da auf, wo ich eine halbwegs sinnvolle u. für meine Bedürfnisse funktionierende Lösung habe. Für mehr ist mir dann die Zeit zu schade, da die brach liegenden Projekte auch nach Erledigung schreien.  :)

Hier mal mein letzter Stand
Zitatelsif ($family eq "DHT") {
      return $return_array .= "|".(ReadingsVal($hash->{NAME},"failures",0)+1)."-open_failure_temp" if (!open DATA, "/sys/devices/platform/dht11@".$id."/iio:device0/in_temp_input");
      my $input = <DATA>;
      return $return_array .= "|".(ReadingsVal($hash->{NAME},"failures",0)+1)."-read_failure_temp" if (!defined($input));
      my $temp = $input/1000.0;
      if ($attr{$hash->{NAME}}{tempOffset}) {
         $temp+=$attr{$hash->{NAME}}{tempOffset};
      }
my $deviation = abs(1.0 - $temp/ReadingsVal($hash->{NAME},"temperature",50000));   # $temp
if ($temp > 19.5) {
   Log3 $hash->{NAME}, 1, "GPIO4: GPIO4_Poll($hash->{NAME}) temperature to high: $temp, old temp: ".ReadingsVal($hash->{NAME},"temperature",$temp).", deviation: ".$deviation;
}
return $return_array .= "|".(ReadingsVal($hash->{NAME},"failures",0)+1)."-value_failure_temp $temp" if ($deviation > 0.05); # $temp

      my @faultvalues = split(" ",AttrVal($hash->{NAME},"faultvalues",""));
      my $fault = 0;   
      for (my $i=0; $i < @faultvalues; $i++) {
         $fault = 1 if($temp == $faultvalues[$i]);
      }

Have fun
Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Zitat von: KölnSolar am 21 Oktober 2021, 11:18:20
Nein. Sowohl mit meinem GPIO4, als auch Deinem OneWire(es werden zwar 3 angezeigt, die sind aber immer 0) habe ich eine Nachkommastelle. Das liegt daher eher(glaub ich) an dem Unterschied DHT11/DHT22. Der 11er hat ja eine geringere Genauigkeit.
Gerade hab ich tatsächlich einen Wert 0 bei humidity mit OneWire beobachtet.
Wir nutzen ja beide die Kernel Schnittstelle - und die liefert zwar 3 Nachkommastellen, aber scheint diese gar nicht zu befüllen.
Mein DHT11 an sich, hat aber eine Nachkommastelle - wird nur ignoriert. Wie gesagt, mit meinem "Hack" von RPi::DHT11 bekomme ich die jetzt. Ich denke das Kernel Modul kann man vergessen. Zu instabil, ungenau und umständlich zu verwenden. Vielleicht schicke ich dir heute abend mal was zum probieren.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Ja gerne. Solange es absturzfrei und nicht dauerblockierend(sich auflösende freezes kann ich ertragen) ist, da ich nur produktiv testen kann.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Wie versprochen was zum Testen.
Einfach irgendwo auf deinem Raspi auspacken und dann im Verzeichnis dht
perl -I - test.pl
Im Idealfall kriegst du dann sowas wie:
Humidity = 70.0 % Temperature = 20.7 *C
T: 207  H: 700
Humidity = 70.0 % Temperature = 20.6 *C
Humidity = 70.0 % Temperature = 20.6 *C
T: 206  H: 700


Ich habe festgestellt, dass ein grosser Nachteil des ursprünglichen Moduls und auch des Kernel Treibers ist, dass man Temperatur und Humidity getrennt abfragen muss.
Auf Sensorebene geht das aber gar nicht - man holt immer beides. Dadurch erhört sich auch die Wahrscheinlichkeit, dass eins von beiden fehl schlägt.

Deswegen hab ich jetzt damit rumexperientiert, stattdessen ein Array zurückgeben ($dev->query)
Anschliessend führt ers nochmal einzeln aus ($dev->temp , $dev->humidity)

Aktuell macht er im Sekundentakt bis zu 3 retries - dann gibt er auf und man bekommt "undef"

Sollte somit als absolut verträglich sein.
Falls jemanden der Source Code interessiert, ich hab auf github einen fork from Original gemacht und meine Änderungen eingecheckt: https://github.com/bublath/rpi-dht11

Edit: Achja - wiringpi muss installiert sein (mit apt)

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

ZitatIm Idealfall kriegst du dann sowas wie
Glaub ich nicht. Wo mach ich denn die Definition des GPIO ?  ;)
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

ZitatEinfach irgendwo auf deinem Raspi
reichte nicht. Das hab ich noch kurzfristig lösen können.
ZitatAchja - wiringpi muss installiert sein (mit apt)
Hab ich natürlich nicht.  ::) Dauert also noch etwas....

Edit: läuft, aber ohne jeglichen Output. Any ideas ? GPIO# nach BCM, oder ?
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Zitat von: KölnSolar am 22 Oktober 2021, 09:48:25
Edit: läuft, aber ohne jeglichen Output. Any ideas ? GPIO# nach BCM, oder ?
BCM, genau - wie beim Kernel Treiber auch.
Mehrmals probiert?
Irgendjemand hatte gemeint beim ih lief es erst wenn noch an einem Timingparameter gedreht wurde. Müsste ich erst konfiguriertbar machen....
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Mehrfach probiert. Nix. Beendet sich ohne Output.
Fehlerquellen, die ich sehe: DHT22(vs. DHT11), noch per dtoverlay eingebunden  :-\
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

#53
dtoverlay macht nichts - das hat bei mir nicht gestört.
Ich hab aber jetzt tatsächlich was gefunden, dass beim DHT22 anders ist (timing bei initialisieren am Anfang).

Man kann jetzt DHT22 einstellen (der dritte Parameter ist "debug"):
RPi::DHT11->new($pin,22,1);

bin gespannt ob das bei dir hilft.

Edit: Hab nochmal weiter am Algorithmus gefeilt (bzw. von einer anderen Quelle "inspirieren" lassen) so dass alles jetzt noch näher an der HW Spec läuft. Mit meinem DHT11 jetzt sehr stabil (schon mit FHEM Modul) - bisher keine fails (ok, er macht intern bis zu 3 retries).
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

schon besser  :D
Humidity = 2.175 % Temperature = 0.163 *C
T: 16.3  H: 19.5
Checksum error or insufficient data
Checksum error or insufficient data
Humidity = 2.175 % Temperature = 0.163 *C
Checksum error or insufficient data
Humidity = 2.175 % Temperature = 0.163 *C
T: 16.3  H: 19.5
T ist ok. H nicht. Ist 63,8%.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Zitat von: KölnSolar am 23 Oktober 2021, 01:45:36
T ist ok. H nicht. Ist 63,8%.
Dann scheint zumindest das Timing der Abfrage jetzt zu passen - diese Checksum Error kriege ich auch - die Sensoren mögen es wohl nicht zu häufig abgefragt zu werden, aber mit den eingebauten retries klappt es eigentlich immer.
Bei meinen zwei DHT11 hatte ich bei Abfrage alle 60 Sekunden über Nacht nicht einen einzigen "failure" in FHEM.

Der Algorithmus für die Umrechung ist nur beim DHT22 auch anders. Tausch mal die angehängte Datei aus, dann klappt es hoffentlich. (nur die T: und H: beachten - die Humidity/Temperature= Ausgabe macht highbyte.lowbyte was beim DHT22 zu Quatsch führt).
Spannend it noch der Sonderfall negative Temperatur - aber das wirst du wahrscheinlich schlecht testen können :)
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Jetzt passt es.  8)

ZitatSpannend it noch der Sonderfall negative Temperatur
Klar. Ich guck mal, ob ich ihn mit Kühlpacks unter 0 kriege.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Zitat von: KölnSolar am 23 Oktober 2021, 11:32:30
Ist Ok: auf -11,7 runtergekühlt.
Perfekt. Dann werd ich das noch entsprechend einbinden, Debian Paket dazu etc.
Werde es dann wohl RPi::DHT nennen, da es Gegensatz zum Vorbild beide DHTs unterstützt.
Frage mich noch wie das der Kerneltreiber macht, der ja auch DHT11 heisst aber bei dir trotzdem geht. Evtl. probiert der einfach durch.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Adimarantis

Ok, jetzt hab mir aus Neugierde mal den Sourcecode vom Kerneltreiber angesehen. Der arbeitet mit Interrupts und kriegt da irgendwie hin beide DHT zu initialisieren (wie genau will ich mich jetzt nicht reindenken) - aber ich weiss jetzt wenigstens warum ich mit den Kerneltreiber fast nie Werte bekommen habe:
Der versucht anhand der Wertezusammensetzung zu erkennen ob die Daten zum DHT11 oder DHT22 passen. Dabei prüft er unter anderem ab ob die Dezimalstellen für Temperatur leer sind - mein Sensor (vielleicht ein neueres Modell) sendet aber 1/10 Grad - und somit streikt der Kerneltreiber ("kenn ich nicht") - mit dem Kernel kriege als nur die Komma Null Messungen.

Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Hi Jörg,
scheinbar liest Du doppelt2021.10.24 17:06:00 2: RPi_OW_TCar1: Poll for temperature took 0.101958 s
2021.10.24 17:06:02 2: RPi_OW_TCar1: Poll for temperature took 0.094962 s
2021.10.24 17:07:02 2: RPi_OW_TCar1: Poll for temperature took 0.093208 s
2021.10.24 17:07:04 2: RPi_OW_TCar1: Poll for temperature took 0.09867 s
2021.10.24 17:08:04 2: RPi_OW_TCar1: Poll for temperature took 0.094438 s
2021.10.24 17:08:05 2: RPi_OW_TCar1: Poll for temperature took 0.098338 s
2021.10.24 17:09:05 2: RPi_OW_TCar1: Poll for temperature took 0.09395 s
2021.10.24 17:09:07 2: RPi_OW_TCar1: Poll for temperature took 0.09655 s
2021.10.24 17:10:07 2: RPi_OW_TCar1: Poll for temperature took 0.099392 s
2021.10.24 17:10:09 2: RPi_OW_TCar1: Poll for temperature took 0.097218 s
2021.10.24 17:11:09 2: RPi_OW_TCar1: Poll for temperature took 0.09739 s
2021.10.24 17:11:10 2: RPi_OW_TCar1: Poll for temperature took 0.094363 s
2021.10.24 17:12:11 2: RPi_OW_TCar1: Poll for temperature took 0.202024 s
2021.10.24 17:12:12 2: RPi_OW_TCar1: Poll for temperature took 0.098524 s
2021.10.24 17:13:12 2: RPi_OW_TCar1: Poll for temperature took 0.095339 s
2021.10.24 17:13:14 2: RPi_OW_TCar1: Poll for temperature took 0.097046 s
2021.10.24 17:14:14 2: RPi_OW_TCar1: Poll for temperature took 0.093119 s
2021.10.24 17:14:16 2: RPi_OW_TCar1: Poll for temperature took 0.097148 s
2021.10.24 17:15:16 2: RPi_OW_TCar1: Poll for temperature took 0.101318 s
2021.10.24 17:15:17 2: RPi_OW_TCar1: Poll for temperature took 0.09525 s
2021.10.24 17:16:17 2: RPi_OW_TCar1: Poll for temperature took 0.096868 s
2021.10.24 17:16:19 2: RPi_OW_TCar1: Poll for temperature took 0.098114 s
2021.10.24 17:17:19 2: RPi_OW_TCar1: Poll for temperature took 0.096775 s
2021.10.24 17:17:21 2: RPi_OW_TCar1: Poll for temperature took 0.098046 s
2021.10.24 17:18:21 2: RPi_OW_TCar1: Poll for temperature took 0.092432 s
2021.10.24 17:18:22 2: RPi_OW_TCar1: Poll for temperature took 0.099036 s
2021.10.24 17:19:23 2: RPi_OW_TCar1: Poll for temperature took 0.097574 s
2021.10.24 17:19:24 2: RPi_OW_TCar1: Poll for temperature took 0.098594 s
2021.10.24 17:20:24 2: RPi_OW_TCar1: Poll for temperature took 0.103044 s
2021.10.24 17:20:26 2: RPi_OW_TCar1: Poll for temperature took 0.096827 s
2021.10.24 17:21:26 2: RPi_OW_TCar1: Poll for temperature took 0.221009 s
2021.10.24 17:21:28 2: RPi_OW_TCar1: Poll for temperature took 0.127375 s
2021.10.24 17:22:28 2: RPi_OW_TCar1: Poll for temperature took 0.094627 s
2021.10.24 17:22:30 2: RPi_OW_TCar1: Poll for temperature took 0.097465 s
2021.10.24 17:23:30 2: RPi_OW_TCar1: Poll for temperature took 0.101513 s
2021.10.24 17:23:31 2: RPi_OW_TCar1: Poll for temperature took 0.098766 s
2021.10.24 17:24:31 2: RPi_OW_TCar1: Poll for temperature took 0.099656 s
2021.10.24 17:24:33 2: RPi_OW_TCar1: Poll for temperature took 0.095701 s
2021.10.24 17:25:33 2: RPi_OW_TCar1: Poll for temperature took 0.096936 s
2021.10.24 17:25:35 2: RPi_OW_TCar1: Poll for temperature took 0.096899 s
2021.10.24 17:26:35 2: RPi_OW_TCar1: Poll for temperature took 0.095325 s
2021.10.24 17:26:36 2: RPi_OW_TCar1: Poll for temperature took 0.096865 s
2021.10.24 17:27:36 2: RPi_OW_TCar1: Poll for temperature took 0.101343 s
2021.10.24 17:27:38 2: RPi_OW_TCar1: Poll for temperature took 0.199141 s
2021.10.24 17:28:38 2: RPi_OW_TCar1: Poll for temperature took 0.09846 s
2021.10.24 17:28:40 2: RPi_OW_TCar1: Poll for temperature took 0.095127 s
2021.10.24 17:29:40 2: RPi_OW_TCar1: Poll for temperature took 0.09286 s
2021.10.24 17:29:42 2: RPi_OW_TCar1: Poll for temperature took 0.095109 s
2021.10.24 17:30:42 2: RPi_OW_TCar1: Poll for temperature took 0.096441 s
2021.10.24 17:30:43 2: RPi_OW_TCar1: Poll for temperature took 0.098809 s
2021.10.24 17:31:43 2: RPi_OW_TCar1: Poll for temperature took 0.096544 s
2021.10.24 17:31:45 2: RPi_OW_TCar1: Poll for temperature took 0.09845 s
2021.10.24 17:32:45 2: RPi_OW_TCar1: Poll for temperature took 0.095375 s
2021.10.24 17:32:47 2: RPi_OW_TCar1: Poll for temperature took 0.094913 s
2021.10.24 17:33:47 2: RPi_OW_TCar1: Poll for temperature took 0.096925 s
2021.10.24 17:33:49 2: RPi_OW_TCar1: Poll for temperature took 0.177198 s
2021.10.24 17:34:49 2: RPi_OW_TCar1: Poll for temperature took 0.09767 s
2021.10.24 17:34:50 2: RPi_OW_TCar1: Poll for temperature took 0.111738 s
2021.10.24 17:35:50 2: RPi_OW_TCar1: Poll for temperature took 0.099235 s

Dadurch wird das Intervall nicht eingehalten.
Weil ich immer noch GPIO4 im Einsatz hab, führt das vermutlich beim konkurrierenden Zugriff zu freezes2021.10.24 17:35:54 2: RPi_OW_TCar1: Poll for temperature took 2.259114 s
2021.10.24 17:35:54 2: [Freezemon] freezedetect: possible freeze starting at 17:35:53, delay is 1.646 possibly caused by: tmr-RPI_1Wire_FromTimer(RPi_OW_TCar1)
2021.10.24 18:10:55 2: RPi_OW_TCar1: Poll for temperature took 2.415079 s
2021.10.24 18:10:55 2: [Freezemon] freezedetect: possible freeze starting at 18:10:54, delay is 1.77 possibly caused by: tmr-RPI_1Wire_FromTimer(RPi_OW_TCar1) tmr-at_Exec(check_jammer)
2021.10.24 18:45:56 2: RPi_OW_TCar1: Poll for temperature took 2.273054 s
2021.10.24 18:45:56 2: [Freezemon] freezedetect: possible freeze starting at 18:45:55, delay is 1.819 possibly caused by: tmr-GPIO4_DeviceUpdateLoop(RPi_OW_WWL) tmr-RPI_1Wire_FromTimer(RPi_OW_TCar1)
2021.10.24 19:19:57 2: RPi_OW_TCar1: Poll for temperature took 3.51826 s
2021.10.24 19:19:57 2: [Freezemon] freezedetect: possible freeze starting at 19:19:55, delay is 2.786 possibly caused by: tmr-GPIO4_DeviceUpdateLoop(RPi_OW_WZ) tmr-GPIO4_DeviceUpdateLoop(RPi_OW_TA) tmr-GPIO4_DeviceUpdateLoop(RPi_OW_TC1) tmr-RPI_1Wire_FromTimer(RPi_OW_TCar1) tmr-GPIO4_DeviceUpdateLoop(RPi_OW_VT)
2021.10.24 19:54:58 2: RPi_OW_TCar1: Poll for temperature took 2.296177 s


Ich denke Du kannst die Zeitmessung auf verbose level 5 setzen.

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Hi Markus,

Wenn die Funktion "fromTimer" aufgerufen wird, dann ist es normal, dass es zwei Aufrufe gibt (im Abstand von 1.5s). Hast du "mode" auf "timer"? Das ist für den Trick mit conv_time=2 gedacht - und dann kann er nicht blockieren, weil die Abfrage ja sofort zurückkommt.
Wenn du das nicht eingestellt hast, bräuchte ich ein "list" vom Device, da ich mir dann nicht erklären kann, warum er das macht.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

ZitatHast du "mode" auf "timer"?
Yes.
Zitatund dann kann er nicht blockieren
Doch, tat es.[Freezemon] freezedetect: possible freeze starting at 19:54:57, delay is 1.754 possibly caused by: tmr-RPI_1Wire_FromTimer(RPi_OW_TCar1)
2021.10.24 19:54:56.397 5: RPi_OW_TCar1: Open /sys/devices/w1_bus_master1/28-000005fa612d/w1_slave
--- log skips     2.295 secs.
2021.10.24 19:54:58.692 5: RPi_OW_TCar1: Read ae 00 4b 46 7f ff 02 10 97 : crc=97 YES
2021.10.24 19:54:58.692 5: RPi_OW_TCar1: Read ae 00 4b 46 7f ff 02 10 97 t=10875
2021.10.24 19:54:58.692 2: RPi_OW_TCar1: Poll for temperature took 2.296177 s
2021.10.24 19:54:58.693 5: RPi_OW_TCar1: Finish: RPi_OW_TCar1 temperature=10.875
2021.10.24 19:54:58.703 5: End notify loop for RPi_OW_TCar1
Wie gesagt, ich denke
ZitatWeil ich immer noch GPIO4 im Einsatz hab, führt das vermutlich beim konkurrierenden Zugriff zu freezes
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

ungern.  ;) Wird nicht großartig erhellen und ich muss erst wieder umändern.  :(
Aber bitte Internals:
   CFGFN     
   DEF        28-000005fa612d
   FUUID      617454c4-f33f-49d8-9852-6a7589159f29b2fe
   NAME       RPi_OW_TCar1
   NOTIFYDEV  global
   NR         886365
   NTFY_ORDER 50-RPi_OW_TCar1
   STATE      T: 9.000
   TYPE       RPI_1Wire
   family     28
   id         000005fa612d
   model      DS18B20
   .attraggr:
   .attrminint:
   READINGS:
     2021-10-25 10:17:06   conv_time       2
     2021-10-21 15:06:59   failreason      empty_data
     2021-10-21 15:06:59   failures        2
     2021-10-25 10:17:06   precision       12
     2021-10-25 10:17:35   state           T: 9.000
     2021-10-25 10:17:35   temperature     9.000
   getList:
     udev       noArg
   helper:
     write      resolution
     RUNNING_PID:
       abortArg   
       abortFn   
       bc_pid     934740
       finishFn   RPI_1Wire_FinishFn
       fn         RPI_1Wire_Poll
       pid        DEAD:13843
       terminated 1
       timeout   
       arg:
   setList:
     conv_time  textField
     update     noArg
Attributes:
   mode       timer
   room       Aussen
   verbose    1

Ich lass es dann mal ne Stunde so laufen und werde dann sicherlich wieder den freeze haben und hier als Edit posten.

Edit: Und schon ist er wieder da
[Freezemon] freezedetect: possible freeze starting at 10:46:24, delay is 1.908 possibly caused by: tmr-at_Exec(check_jammer) tmr-RPI_1Wire_FromTimer(RPi_OW_TCar1)
2021.10.25 10:46:23.424 5: exec at command check_jammer
2021.10.25 10:46:23.425 5: Cmd: >{if (ReadingsAge('TRXUSB','state',0) > 40 || ReadingsVal('CULFB','state','opened') ne 'Initialized') {Voicecmd('jammer')}}<
2021.10.25 10:46:23.427 5: redefine at command check_jammer as +*00:00:05 {if (ReadingsAge('TRXUSB','state',0) > 40 || ReadingsVal('CULFB','state','opened') ne 'Initialized') {Voicecmd('jammer')}}
2021.10.25 10:46:23.453 5: End notify loop for check_jammer
2021.10.25 10:46:23.596 5: RPi_OW_TCar1: Open /sys/devices/w1_bus_master1/28-000005fa612d/w1_slave
--- log skips     2.296 secs.
2021.10.25 10:46:25.892 5: RPi_OW_TCar1: Read b0 00 4b 46 7f ff 10 10 07 : crc=07 YES
2021.10.25 10:46:25.892 5: RPi_OW_TCar1: Read b0 00 4b 46 7f ff 10 10 07 t=11000
2021.10.25 10:46:25.892 2: RPi_OW_TCar1: Poll for temperature took 2.296319 s
2021.10.25 10:46:25.892 5: RPi_OW_TCar1: Finish: RPi_OW_TCar1 temperature=11
2021.10.25 10:46:25.902 5: End notify loop for RPi_OW_TCar1
2021.10.25 10:46:25.906 4: Connection accepted from telnetForBlockingFn_1633424004_127.0.0.1_41584
2021.10.25 10:46:25.909 5: [Freezemon] freezedetect: ----------- Starting Freeze handling at 2021.10.25 10:46:25.908 ---------------------
[Freezemon] freezedetect: possible freeze starting at 10:46:24, delay is 1.908 possibly caused by: tmr-at_Exec(check_jammer) tmr-RPI_1Wire_FromTimer(RPi_OW_TCar1)
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Mal sehen ob das am Modul oder am System liegt. Kannst du mal auf der Kommandozeile (in /sys/device/w1_bus_master1/28-xxx/)
time cat w1_slave
machen.
Ruhig paar mal wiederholen.
Erwartung bei conv_time=2 wäre das dies in der Gegend von 0,1xx Sekunden liegt.
64 01 55 05 7f a5 81 66 7c : crc=7c YES
64 01 55 05 7f a5 81 66 7c t=22250

real    0m0,131s
user    0m0,001s
sys     0m0,026s
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Vielleicht habe ich mit dem letzten Zugriff tatsächlich einen konkurrierenden Zugriff erwischt
pi@raspberrypi:~ $ time cat /sys/devices/w1_bus_master1/28-000005fa612d/w1_slave
28 01 4b 46 7f ff 08 10 4c : crc=4c YES
28 01 4b 46 7f ff 08 10 4c t=18500

real    0m0.137s
user    0m0.013s
sys     0m0.025s
pi@raspberrypi:~ $ time cat /sys/devices/w1_bus_master1/28-000005fa612d/w1_slave
27 01 4b 46 7f ff 09 10 72 : crc=72 YES
27 01 4b 46 7f ff 09 10 72 t=18437

real    0m0.107s
user    0m0.001s
sys     0m0.025s
pi@raspberrypi:~ $ time cat /sys/devices/w1_bus_master1/28-000005fa612d/w1_slave
27 01 4b 46 7f ff 09 10 72 : crc=72 YES
27 01 4b 46 7f ff 09 10 72 t=18437

real    0m0.105s
user    0m0.001s
sys     0m0.022s
pi@raspberrypi:~ $ time cat /sys/devices/w1_bus_master1/28-000005fa612d/w1_slave
27 01 4b 46 7f ff 09 10 72 : crc=72 YES
27 01 4b 46 7f ff 09 10 72 t=18437

real    0m0.105s
user    0m0.001s
sys     0m0.023s
pi@raspberrypi:~ $ time cat /sys/devices/w1_bus_master1/28-000005fa612d/w1_slave
27 01 4b 46 7f ff 09 10 72 : crc=72 YES
27 01 4b 46 7f ff 09 10 72 t=18437

real    0m0.107s
user    0m0.001s
sys     0m0.023s
pi@raspberrypi:~ $ time cat /sys/devices/w1_bus_master1/28-000005fa612d/w1_slave
27 01 4b 46 7f ff 09 10 72 : crc=72 YES
27 01 4b 46 7f ff 09 10 72 t=18437

real    0m1.658s
user    0m0.001s
sys     0m0.026s
pi@raspberrypi:~ $
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Ich habe eine Vermutung:
Du hast nicht alle deine Sensoren auf conv_time=2 umgestellt.
Da die Abfragen alle über den selben 1Wire Bus laufen, blockieren die "langsamen" Sensoren, die schnellen trotzdem (müssen warten bis der Bus frei wird). Zumindest kann ich dein Bild nur auf diese Weise bei mir nachstellen. Wenn alle umgestellt sind, sehe ich bei zwei Sensoren die beide parallel von GPIO4 und RPI_1Wire bedient werden, selbst bei 5s update keine Ausreisser.

Ich könnte mir so als Feature noch vorstellen, dass ich mir die letzten 3 Zeiten merke und wenn der Durchschnitt >1s ist einen Hinweis in der Modulübersicht gebe (falls timer oder blocking) dass die Einstellung nonblocking die bessere Idee wäre.


Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

ZitatDu hast nicht alle deine Sensoren auf conv_time=2 umgestellt.
Natürlich nicht. Laufen alle mit GPIO4.
Ich teile Deine Vermutung aber nicht. Der freeze tritt ja offensichtlich nur bei KONKURRIERENDEM Zugriff auf DENSELBEN Sensor(siehe 7 Posts zurück).
ZitatIch könnte mir so als Feature noch vorstellen, dass ich mir die letzten 3 Zeiten merke und wenn der Durchschnitt >1s ist einen Hinweis in der Modulübersicht gebe (falls timer oder blocking) dass die Einstellung nonblocking die bessere Idee wäre.
Bloß nicht. Das wird ja immer komplizierter. Und 99,9% werden sowieso die default-Einstellung nutzen, die ja problemlos funktioniert.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Zitat von: KölnSolar am 25 Oktober 2021, 16:16:06
Ich teile Deine Vermutung aber nicht. Der freeze tritt ja offensichtlich nur bei KONKURRIERENDEM Zugriff auf DENSELBEN Sensor(siehe 7 Posts zurück).
Je nachdem wieviele Sensoren du hast, ist das schwer zu bestimmen. Mit zwei Sensoren (einer konkurriert mit GPIO4) schaffe ich zumindest keine Freezemon Hits. Und auf meinen Produktivsystemen hab ich aktuell nur nonblocking im Einsatz (und natürlich komplett umgestellt).
Zitat
Bloß nicht. Das wird ja immer komplizierter. Und 99,9% werden sowieso die default-Einstellung nutzen, die ja problemlos funktioniert.
Ein Hinweis, dass man möglicherweise etwas falsch eingestellt hat, sollte es doch nicht komplizierter machen, sondern eher unnötige Supportanfragen vermeiden. Aber wie du schon sagst, ist das Feature nur für wenige überhaupt relevant.

Ich habe jetzt trotzdem mal das therm_bulk_read feature eingebaut (wie üblich in dem anderen thread im ersten Post: https://forum.fhem.de/index.php/topic,123499.0.html). Einen Bug mit der conv_time hatte ich noch gefunden, aber der würde dich erst nach einem "shutdown restart" erwischen - da wurde die conv_time nicht wieder gesetzt.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)