[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

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