FHEM Forum

FHEM - Hardware => Einplatinencomputer => Thema gestartet von: Punkt am 15 Februar 2013, 22:51:04

Titel: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: Punkt am 15 Februar 2013, 22:51:04
Hallo,

ich bin gerade dabei mir ein Testsystem mit meinem RaspberryPi aufzusetzen.
Die Installation von FHEM ging ja recht flott innerhalb von ein paar Minuten.

Nun stehe ich aber vor einer Frage, die mir durch die Suche bisher nicht beantwortet wurde (oder ich war zu doof zum Suchen :-) ):

Ich habe meinen 1wire-Bus direkt am RaspberryPi angeschlossen über den GPIO4 und nutze die Kernelmodule w1-gpio und w1-therm um z.B. mit meinen DS18B20 Temperaturen auszulesen.

In den ganzen Anleitungen finde ich allerdings nur Hinweise wie man 1wire-Komponenten über andere Bus-Master in FHEM einbindet (also über USB-Module usw.).

Beim direkten Anbinden des 1wire-Busses am Raspberry befinden sich die devices in /sys/bus/w1/devices und sind dort mit ihrer eindeutigen ID auslesbar.

Gibt es irgendwie eine Möglichkeit, diese 1wire-Komponenten auch in FHEM einzubinden?
Gibt es dazu irgendwo eine Anleitung bzw. Hinweise, wie ich dabei vorgehen kann?


Vielen Dank schonmal im Voraus und
viele Grüße

Michael
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: le66ck am 17 Februar 2013, 08:55:14
Hallo Michael

Du bist nicht doof, zumindesten von meinen Horizont aus nicht!
Es gibt für Dein Problem eine ganz einfache Lösung, die schon einer ganz genial umgesetzt hat!!!
Für nur Temeratur messen sind mir die anderen Lösungen zu aufwendig.
Du brauchst die Datei/Modul von hier

https://github.com/mhop/fhem-mirror/blob/master/contrib/58_GPIO4.pm (//github.com/mhop/fhem-mirror/blob/master/contrib/58_GPIO4.pm)

Da ich nicht weis wie man die einzelne Datei herunterlädt, habe ich den Inhalt in eine Datei selbigen Namens eingefügt und in das
"Fhem Verzeichnis" kopiert und die selben Rechte wie die anderen "*.pm-Dateien" gegeben.
Jetzt sollte ein "define <Dein Name> GPIO4 <Deine Seriennummer z.B. 28-000003e159fb>" reichen.
Kanns bei mir momentan nicht nachvollziehen.
Hinweis es können max nur 10 Temp-sensoren angeschlossen werden, geben die Kernelmodule w1-gpio und w1-therm vor!

Zuletzt bin ich bei der Grafik stecken geblieben. Habs irgendwie nur für einen Sensor hinbekommen, für mehrere nicht. Fehlt mir noch das Wissen...!
Vielleicht führt das hier dazu einen Wikiartikel zu erschaffen!!!???

MFG CK
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: mattes1007 am 17 Februar 2013, 12:24:54
define <name> GPIO4 BUSMASTER fügst du in der fhem.cfg ein.
Vorher natürlich das Modul 58_GPIO4.pm in /opt/fhem/FHEM/ einfügen.

Dann fhem neu starten und deine Devices werden automatisch in der fhem.cfg angelegt
und erscheinen in room GPIO4.

Danach hab ich in der cfg noch

define weblink_GPIO4_DS18B20_xxxxxxxxx weblink fileplot FileLog_GPIO4_DS18B20_xxxxxxxxx:temp4:CURRENT
attr weblink_GPIO4_DS18B20_xxxxxxxxxxx label "T_Ferns Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr weblink_GPIO4_DS18B20_xxxxxxxxxx room GPIO4

die xxxxxxxx ersetzt du mit deinen Daten.

Dann noch ein shutdown restart und es laüft

Gruß Mattes





 
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: fladdy am 17 Februar 2013, 19:10:28
Zitat von: le66ck schrieb am So, 17 Februar 2013 08:55Du brauchst die Datei/Modul von hier

https://github.com/mhop/fhem-mirror/blob/master/contrib/58_GPIO4.pm

Hallo Zusammen,

da das GPIO4-Modul von mir ist, nur noch kurz der Hinweis, dass ich (wenn überhaupt) neue Versionen nicht im angegebenen Github-Fork pflege. Stattdessen ist (mein) letztes Update im FHEM repository auf SourceForge zu finden.

Anbei nochmal ein Patch für autocreate, den ich benutze, um auch die GPIO4-Plots automatisch zu erzeugen.

Grüße
Peter
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: Punkt am 17 Februar 2013, 22:26:57
Hallo,

ich hab das jetzt mal versucht einzufügen - bekomme aber immer folgende Fehlermeldungen im Log:

2013.02.17 21:11:00 1: reload: Error:Modul 58_GPIO4 deactivated:
 Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 58 at ./FHEM/58_GPIO4.pm line 9, <$fh> line 41.

2013.02.17 21:11:00 0: Unrecognized character \xC2; marked by <-- HERE after at master <-- HERE near column 58 at ./FHEM/58_GPIO4.pm line 9, <$fh> line 41.

2013.02.17 21:11:00 1: configfile: Cannot load module GPIO4


Kann mir da jemand weiterhelfen?
Oder gibts mittlerweile ne neuere Version?

Bei Sourceforge hab ich leider die 58_GPIO.pm nicht gefunden...


Viele Grüße

Michael
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: Punkt am 17 Februar 2013, 23:14:29
hmm.....

ich hab jetzt grade mal bei sourceforge nachgeschaut und dort die 58_GPIO.pm gefunden.

....ich weis jetzt nicht, welche Datei die richtige ist - aber die beiden Dateien sind sehr unterschiedlich... :-)

ich werde das mal durchprobieren... :-)


Viele Grüße

Michael
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: Punkt am 18 Februar 2013, 00:35:55
Hallo zusammen,

ich kriegs einfach nicht zum laufen....
Ich hab jetzt scheinbar die korrekte Version von 58_GPIO.pm - allerdings startet FHEM jetzt nicht mehr.

wenn ich mit

sudo service fhem start

starte hab ich folgende Fehlermeldung:

Undefined subroutine &main::readingsBulkUpdate called at ./FHEM/58_GPIO4.pm line 140, <DATA> line 2.


Viele Grüße

Michael
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: Punkt am 18 Februar 2013, 01:00:11
....Kommando zurück! :-)

Kaum macht man es richtig - schon funktionierts!

Nach einem Update von FHEM läuft es jetzt und ich hab meinen "Raum" GPIO4 und kann meine Temperaturen auslesen...juhuu! :-)


Viele Grüße

Michael
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: le66ck am 18 Februar 2013, 15:09:25
Hallo fladdy

Danke, danke,.... es geht. Hab mich zwischendurch etwas dooof angestellt, naja...!
Wo ist Dein letztes Update bei SourceForge, habs nicht gefunden!? Oder der Satz zuvor...!
Heißt die dort auch 58_GPIO4.pm?

Noch mal für alle, was ich gemacht habe.

- mehrere DS18B20 mit einem 4,7k Widerstand an GPIO4 angeschlossen
- "w1-gpio" und "w1-therm" in /etc/modules eingetragen und rebootet
- dann hier /sys/bus/w1/devices/w1_bus_master1/ geschaut ob sie erkannt wurden
  z.B. sieht das so aus /sys/bus/w1/devices/w1_bus_master1/10-000801216380
  auch hier nachzulesen http://wiki.laub-home.de/wiki/Raspberry_Pi_Sensoren_auslesen (//wiki.laub-home.de/wiki/Raspberry_Pi_Sensoren_auslesen)
- von hier https://github.com/mhop/fhem-mirror/blob/master/contrib/58_GPIO4.pm (//github.com/mhop/fhem-mirror/blob/master/contrib/58_GPIO4.pm)   die 58_GPIO4.pm geholt, siehe weiter oben
- dann den Patch von fladdy in 98_autocreate.pm eingefügt
  also im Endefekt das hier

 # GPIO
 "GPIO4_(DS18B20|DS1820).*"
   => { GPLOT => "temp4:Temp,", FILTER => "%NAME" },

  Wenns zum Patchen ein Befehl gibt, bitte mal posten!?
-shutdown  restart von Fhem ist bestimmt hier nicht falsch
-dann in Fhem  define <z.B.1wire...irgendwas> GPIO4 BUSMASTER  eingegeben
-shutdown  restart von Fhem
-fertig und hoffentlich freuen!!!

Tschüß
CK
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: fladdy am 18 Februar 2013, 15:16:24
Zitat von: le66ck schrieb am Mo, 18 Februar 2013 15:09Wo ist Dein letztes Update bei SourceForge, habs nicht gefunden!? Oder der Satz zuvor...!

Aktuelle Verison ist 2754 mit stateFormat-Support:
http://fhem.svn.sourceforge.net/viewvc/fhem/trunk/fhem/contrib/


Zitat von: le66ck schrieb am Mo, 18 Februar 2013 15:09Wenns zum Patchen ein Befehl gibt, bitte mal posten!?

Der Befehl heißt "patch" :-)

Grüße
Peter
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: le66ck am 18 Februar 2013, 15:31:04
ok

Da war ich heut schon mal, war bestimmt zu viel Wald da.... oder Bäume...!

Zum Patchen, kannst Du da mal noch was mehr schreiben?

patch 98_autocreate.pm "Dein patch" oder wie?

CK
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: fladdy am 18 Februar 2013, 15:45:48
Zitat von: le66ck schrieb am Mo, 18 Februar 2013 15:31ok

Da war ich heut schon mal, war bestimmt zu viel Wald da.... oder Bäume...!

Zum Patchen, kannst Du da mal noch was mehr schreiben?

patch 98_autocreate.pm "Dein patch" oder wie?

CK

(1) Speichere den Patch unter dem Namen "autocreate_GPIO4.patch" in Deinem Home-Verzeichnis ab.
(2) Geh' in das FHEM-Verzeichnis, in dem die Datei "98_autocreate.pm" liegt.
(3) ... und führe den Patch aus (siehe unten)


cd /opt/fhem/FHEM
sudo patch < ~/autocreate_GPIO4.patch


Schau Dir ruhig mal die Manual-Pages zu "diff" und "patch" an; braucht man immer mal...


man patch
man diff


Grüße
Peter
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: le66ck am 18 Februar 2013, 16:41:22
Danke
CK
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: Patrick am 01 März 2013, 14:30:01
Hallo,

ich habe das Modul 58_GPIO4.pm jetzt auch aktualisiert, seitdem bekomme ich jetzt immer folgende Meldungen auf der Shell des RPI:

Use of uninitialized value $model in concatenation (.) or string at /usr/share/fhem/FHEM/58_GPIO4.pm line 113.
Use of uninitialized value $id in concatenation (.) or string at /usr/share/fhem/FHEM/58_GPIO4.pm line 113.
Use of uninitialized value $model in concatenation (.) or string at /usr/share/fhem/FHEM/58_GPIO4.pm line 114.
Use of uninitialized value $id in concatenation (.) or string at /usr/share/fhem/FHEM/58_GPIO4.pm line 114.

Was kann ich hier tun?
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: fladdy am 01 März 2013, 15:31:22
Ist Dein Fhem insgesamt auf dem neusten Stand?
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: Patrick am 01 März 2013, 15:54:19
ja, "sollte" es eigentlich sein (sollte ist ein ANfänger sollte)

OK, hab jetzt noch nen Neustart des Raspberry gemacht, jetzt scheint es wieder zu gehen, sorry zu voreilig gewesen...
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: ajoreis am 03 März 2013, 20:37:23
Hallo,

ich habe ad Modul auch bei mir eingebaut und bekomme folgene Fehler:

2013.03.03 20:31:30 1: reload: Error:Modul 58_GPIO4 deactivated:
 Global symbol "$readingFnAttributes" requires explicit package name at ./FHEM/58_GPIO4.pm line 42, <$fh> line 55.

2013.03.03 20:31:30 0: Global symbol "$readingFnAttributes" requires explicit package name at ./FHEM/58_GPIO4.pm line 42, <$fh> line 55.

2013.03.03 20:31:30 1: configfile: Cannot load module GPIO4

Kann mir jemand einen Tip geben was falsch ist.

Ich habe das aktuelle Modul genomen und auch das Patch ausgeführt, der Sensor läuft, wenn ich testhalber heraus nehmen bleibt der fhem beim starten stehen.

Hier mein Eintag in der fhem.cfg:
#Raspbarry-pi GPio4 Busmaster
define Wohnzimmer GPIO4 BUSMASTER

Danke für eine kleine Info

Olaf
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: fladdy am 03 März 2013, 20:40:34
Das hört sich für mich danach an, als sei FHEM nicht auf dem letzten Stand.
Hast Du mal ein update durchgeführt?
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: ajoreis am 03 März 2013, 20:50:49
version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 1996 2012-10-20 07:11:56Z rudolfkoenig $

Sollte das nicht der aktuelle stand sein ?
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: fladdy am 03 März 2013, 20:55:25
Nee, ich glaube, da musst Du nochmal 'ran :-)


version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2835 2013-03-01 11:09:18Z rudolfkoenig


Zitat von: ajoreis schrieb am So, 03 März 2013 20:50version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 1996 2012-10-20 07:11:56Z rudolfkoenig $

Sollte das nicht der aktuelle stand sein ?
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: fladdy am 03 März 2013, 21:00:28
So geht's: (Ich habe nur "telnet localhost 7072" und "update" eingegeben)


pi@raspberrypi ~ $ telnet localhost 7072
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.


SecurityCheck:

WEB,WEBphone,WEBtablet has no basicAuth attribute.
telnetPort has no password/globalpassword attribute.

Restart fhem for a new check if the problem is fixed,
or set the global attribute motd to none to supress this message.

fhem> update

Saving statefile: done

Backup:

backup done: FHEM-20130303_205835.tar.gz (11333692 Bytes)

7 file(s) have been updated:
==> 2013-03-03 07:45:22 FHEM/00_FBAHA.pm
==> 2013-03-03 07:45:22 FHEM/10_ZWave.pm
==> 2013-03-02 07:45:16 FHEM/30_HUEBridge.pm
==> 2013-03-02 07:45:16 FHEM/31_HUEDevice.pm
==> 2013-03-03 07:45:22 FHEM/73_PRESENCE.pm
==> 2013-03-03 07:45:23 docs/commandref.html
==> 2013-03-03 07:45:23 docs/commandref_DE.html

Update completed!
fhem>


Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: ajoreis am 03 März 2013, 21:09:53
Super Besten Dank

jetzt klappt es, so jetzt mache ich Feierabend

Nochmals DANK
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: RoBue am 25 April 2013, 10:56:41
Hi fladdy u.a.

auch ich bin mit dem GPIO4-Modul und RPi eingestiegen,
um meine u.a. 1-Wire-Slaves (Clones) zu testen.

-> Link (http://forum.fhem.de/index.php?topic=12237.0)

Die Sache läuft ganz gut. Danke für das Modul, fladdy!

Mir ist es inzwischen gelungen, neben meinen Clones
auch noch den DS2423 in das Modul einzubinden.


(siehe Anhang / see attachement)


Besteht Interesse an dem Code?

Könntest Du mal drübergehen?

Ich könnte mir vorstellen, auch noch den DS2408 einzubinden.
(Leider fehlen den Kernel-Modulen z.B. der DS2450, DS2413, ...
Hätte da jemand Lust, mit mir das zu ändern?
C-Kenntnisse wären wichtig.

Liebe Grüße,
RoBue
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: fladdy am 25 April 2013, 18:25:17
Cool!

Leider habe ich momentan und auch in naher Zukunft keine Zeit, mich um das Modul zu kümmern. Daher habe ich auch nie versucht, das von contrib in die Produktion zu überführen. Möchtest Du Deine Änderungen nicht einfach selber einchecken und die Wartung des Moduls übernehmen?

Grüße
Fladdy
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: RoBue am 27 April 2013, 20:28:12
Hi fladdy und co,

jetzt bin ich einen großen Schritt weiter!
Der DS2408 ist nun drin ...


(siehe Anhang / see attachement)


... aber bisher nur "passiv,
d.h. ich kann die Werte auslesen.
Hier der Code für den Sensor:


sub GPIO4_Get($)
...        
# DS2408-Sensor, ID: 0x29
elsif ($family eq "29") {
my $datastring="";
my $ds2408_datafile="/sys/bus/w1/devices/$hash->{DEF}/output";
open(DS2408_READ,"dd if=$ds2408_datafile bs=1 count=1 2> /dev/null | hexdump |");
$datastring=<DS2408_READ>;
close DS2408_READ;
$datastring=substr($datastring, 10, 2);
my $data_bin=sprintf "%008b", hex ($datastring);
my @pio=split("",$data_bin);
readingsBeginUpdate($hash);
readingsBulkUpdate($hash,"state","8xPIO: $data_bin");
my $j = 7;
for (my $i=0; $i<8; $i++) {
$j=7-$i;
readingsBulkUpdate($hash,"pios.$i",$pio[$j]);
}
readingsEndUpdate($hash,1);
}
...


Kann mir nun jemand auf die Sprünge helfen,
das Ganze aktiv zu steuern,
also die Dinger (PIOs) auch zu schalten?
Was muss dafür in den Code noch rein?
Es gibt darin bisher keine "set"-Routine, die ich als Vorlage nutzen kann.
Die PIOs selbst kann ich ansprechen (bash), aber wie läuft das unter FHEM?

Liebe Grüße,
RoBue

PS: Es reicht evtl. auch ein Link/Hinweis auf ein ähnliches Perl-Modul etc.
Titel: Aw: 1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: RoBue am 29 April 2013, 10:23:01
Hi Leute,

in diesem Thread läuft eine Diskussion zum gleichen oder ähnlichen Thema (RPi und GPIO4):

-> Link (http://forum.fhem.de/index.php?topic=12538.0)

(nur zur Info)

RoBue
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 04 Februar 2018, 15:53:38
Ich habe das Modul auf BlockingCall angepasst, so dass es jetzt keine Probleme mehr als FHEM-Bremse macht. Ich hatte Freezes von bald 10 Sek. und nun schnurrt FHEM wie ein Kätzchen.

Basis war (glaub) ich die Version von RoBue aus dem hiesigen Thread.
Grüße Markus
Edit: habs erst einmal wieder rausgenommen, weil es wohl Probleme mit der Aktualisierung gibt  :-\
Edit2: Sorry an denjenigen, der bereits runtergeladen hat, bevor mir der Fehler aufgefallen war  :-[ Mir war nicht klar, dass im BlockingCall keine events geschrieben werden, wohl aber die Logeinträge generiert werden  ???
Ist nun korrigiert. Aber bitte ausgiebig testen, bevor ihr eure Heizung oder sonstige lebenswichtige Dinge produktiv steuert ! Ich musste dann doch ne ganze Menge am Code ändern, so dass sich leicht Tippfehler eingeschlichen haben können.
Edit3: Anhang wg. neuer Version gelöscht
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 29 März 2020, 19:21:31
zwischenzeitlich war mir aufgefallen, dass beim Wechsel zum Detailsview ein get ausgeführt wird, welches immer noch blockierte. Ich hab daher die mit dem Wechsel zur Detailsview einhergehende Aktualisierung entfernt.

Außerdem einen set-Befehl precision eingeführt. Damit lässt sich eben die precision verändern:
ZitatThe resolution of the DS18B20 is configurable (9, 10, 11, or 12 bits), with 12-bit readings the factory default state.  This equates to a temperature resolution of 0.5°C, 0.25°C, 0.125°C, or 0.0625°C.

Für die performance hat das dank meiner Umstellung auf blockingcall keine besondere Bedeutung mehr(je höher die resolution, desto länger dauert die Aktualisierung). Es kann aber hilfreich sein, wenn man events reduzieren oder keine kleinen Temp.schwankungen gelogged haben möchte.
Vorgehensweise:
Schreibberechtigung für jedermann für die entsprechende Systemdatei /sys/devices/w1_bus_master1/IDdesSensors/w1_slave setzen z.B.
sudo chmod 777 /sys/devices/w1_bus_master1/IDdesSensors/w1_slave
set sensor-device precision 9/10/11/12
um es dauerhaft zu speichern noch ein
set sensor-device precision 0
(nur für ds18b20, also family-id=28 bzw. sensor-id 28-........)
Have fun
Markus

Edit: Attachement wg. neuer Version entfernt.
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 01 April 2020, 21:51:41
Da immer wieder fehlerhafte Temperaturen(0, 85, 127) in den readings landen, habe ich ein neues Attribut faultvalues eingebaut. Dort kann man space-separiert die Werte eintragen, die dann weder ein event, noch ein reading auslösen. Hier war die Diskussion (https://forum.fhem.de/index.php/topic,109640.msg1037158.html#msg1037158).
Tritt ein faultvalue auf, wird er bei verbose=4 gelogged.

attr mySensor faultvalues 0 85 127
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: bismosa am 29 November 2020, 17:49:21
Hallo!

Auch wenn ich einen alten Thread ausgrabe...

Ich bin derzeit auf Fehlersuche bei meinem neuen Raspberry. Freezemon hat bei mir die meisten Einträge bei gpio4 gezeigt. Nach ein wenig Googlen bin ich auf diesen Beitrag gestoßen.
Danke! Endlich keine freezes mehr bei GPIO4.

Ich musste nach dem kopieren der Datei neben einem "shutdown restart" einmal mein "Busmaster" Device einmal neu aufrufen (einmal die DEF bestätigen).
Erst dann fing es an zu funktionieren. Vorher gab es ein paar Log-Fehlermeldungen...aber so ist es nicht schlimm.

Schön wäre es, wenn die Datei unter "contrib" ausgetauscht werden würde. Oder besser gleich mit ins Update wandern würde.  :)

Gruß
Bismosa
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: bismosa am 30 November 2020, 09:30:48
Hallo!

Irgendwie funktioniert es leider doch nicht so richtig bei mir  :(

Ich musste meinen Raspberry neu starten und nun habe ich wieder das Problem, das einige Sensoren sich nicht auslesen lassen.

Mit dieser Version des Moduls erhalte ich nun minütlich mehrere Einträge im Log mit:

1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/58_GPIO4.pm line 211.

Hier wird dann logischerweise nur noch "failures" hochgezählt und ich bekomme keine neuen Werte.

Ich vermute, dass die Sensoren nicht schnell genug geantwortet haben?
Wenn ich in der Konsole die Sensoren auslese

cat /sys/bus/w1/devices/28*/temperature

erhalte ich von allen10 Sensoren gültige Werte.

Ich habe mal im Modul in Zeile 205 auf Log1 gestellt um zu sehen, bei welchen Sensoren dies passiert. Interessanterweise immer mal wieder andere und nicht immer:

2020.11.30 09:24:34 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Drempel_Strasse)
2020.11.30 09:24:34 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Thekla)
2020.11.30 09:25:19 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Netzteil)
2020.11.30 09:25:20 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Werkstatt)
2020.11.30 09:25:20 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Kaltwasser)
2020.11.30 09:25:33 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Dachboden)
2020.11.30 09:25:33 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Spielzimmer)
2020.11.30 09:25:33 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Drempel_Bad)
2020.11.30 09:25:34 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Tamara)
2020.11.30 09:25:34 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Bad_oben)
2020.11.30 09:25:34 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Drempel_Strasse)
2020.11.30 09:25:34 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Thekla)
2020.11.30 09:26:20 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Netzteil)
2020.11.30 09:26:20 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Werkstatt)
2020.11.30 09:26:20 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Kaltwasser)
2020.11.30 09:26:33 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Dachboden)
2020.11.30 09:26:33 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Spielzimmer)
2020.11.30 09:26:34 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Drempel_Bad)
2020.11.30 09:26:34 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/58_GPIO4.pm line 211.
2020.11.30 09:26:34 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Tamara)
2020.11.30 09:26:34 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Bad_oben)
2020.11.30 09:26:34 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Drempel_Strasse)
2020.11.30 09:26:34 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/58_GPIO4.pm line 211.
2020.11.30 09:26:34 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Thekla)
2020.11.30 09:27:20 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Netzteil)
2020.11.30 09:27:20 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Werkstatt)
2020.11.30 09:27:20 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Kaltwasser)
2020.11.30 09:27:33 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Dachboden)
2020.11.30 09:27:33 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Spielzimmer)
2020.11.30 09:27:34 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Drempel_Bad)
2020.11.30 09:27:34 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/58_GPIO4.pm line 211.
2020.11.30 09:27:34 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Tamara)
2020.11.30 09:27:34 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Bad_oben)


Was kann ich tun, um den Fehler zu finden?

Gruß
Bismosa
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 30 November 2020, 22:27:29
ZitatIrgendwie funktioniert es leider doch nicht so richtig bei mir  :(
dachte ich es mir doch. Das
ZitatIch musste nach dem kopieren der Datei neben einem "shutdown restart" einmal mein "Busmaster" Device einmal neu aufrufen (einmal die DEF bestätigen).
Erst dann fing es an zu funktionieren.
war nicht logisch nachvollziehbar.

Zeile 211 sieht in meiner Version so aus if (<DATA> =~ /YES/) { und die Zeile davorreturn $return_array .= "|".(ReadingsVal($hash->{NAME},"failures",0)+1) if (!open DATA, "/sys/bus/w1/devices/$hash->{DEF}/w1_slave");
hieße also: kein return, da das open des files wahr zurückliefert. Dann aber <DATA> uninitialized ? ???

ZitatIch vermute, dass die Sensoren nicht schnell genug geantwortet haben?
Glaube ich eher nicht. Du schriebst ja in dem anderen Thread, dass Dir der Umstieg Rpi3 auf 4 auch andere Probleme bereitet. Ich tippe auf den neuen Rpi. Bei meinem 3er hab ich mit buster keinerlei Problemde bei(ich glaube) 12 schlecht   ::) verdrahteten Sensoren.
Kansst Du testweise zurück auf den 3er ?
Nicht die Lösung, aber Symptombekämpfung
if (<DATA> && <DATA> =~ /YES/) {(ungetestet)
Grüße Markus
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: bismosa am 01 Dezember 2020, 09:49:18
Hallo!

Ich versuche mich schrittweise an den Problemen...es werden irgendwie ja nicht weniger  :(

Zitat von: KölnSolar am 30 November 2020, 22:27:29
hieße also: kein return, da das open des files wahr zurückliefert. Dann aber <DATA> uninitialized ? ???
So hatte ich die Zeile bisher auch (nicht) verstanden.

Ich habe jetzt mal das Modul angepasst um zu sehen, was denn wirklich (nicht) kommt.
Zeile 209-212:

open DATA, "/sys/bus/w1/devices/$hash->{DEF}/w1_slave";
Log 1, "GPIO4: ".<DATA>;
return $return_array .= "|".(ReadingsVal($hash->{NAME},"failures",0)+1) if (!open DATA, "/sys/bus/w1/devices/$hash->{DEF}/w1_slave");
if (<DATA> =~ /YES/) {

So sieht es dann im Log aus:

2020.12.01 09:36:07 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Dachboden)
2020.12.01 09:36:08 1: GPIO4: 5c 00 4b 46 7f ff 0c 10 ea : crc=ea YES

2020.12.01 09:36:08 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Spielzimmer)
2020.12.01 09:36:09 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/58_GPIO4.pm line 212, <DATA> line 1.
2020.12.01 09:36:09 1: GPIO4: 43 01 4b 46 7f ff 0c 10 79 : crc=79 YES

2020.12.01 09:36:09 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Drempel_Bad)
2020.12.01 09:36:09 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/58_GPIO4.pm line 210.
2020.12.01 09:36:09 1: GPIO4:
2020.12.01 09:36:11 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_K1)
2020.12.01 09:36:12 1: GPIO4: 2a 01 4b 46 7f ff 0c 10 f1 : crc=f1 YES

2020.12.01 09:36:12 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Bad_oben)
2020.12.01 09:36:13 1: GPIO4: 2a 01 4b 46 7f ff 0c 10 f1 : crc=f1 YES

2020.12.01 09:36:14 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Drempel_Strasse)
2020.12.01 09:36:15 1: GPIO4: f6 00 4b 46 7f ff 0c 10 7c : crc=7c YES

2020.12.01 09:36:16 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_K2)
2020.12.01 09:36:16 1: GPIO4: 24 01 4b 46 7f ff 0c 10 48 : crc=48 YES

2020.12.01 09:36:29 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Netzteil)
2020.12.01 09:36:30 1: GPIO4: 19 02 4b 46 7f ff 0c 10 8f : crc=8f YES

2020.12.01 09:36:30 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Werkstatt)
2020.12.01 09:36:30 1: GPIO4: 0b 01 4b 46 7f ff 0c 10 1a : crc=1a YES

2020.12.01 09:36:34 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Kaltwasser)
2020.12.01 09:36:35 1: GPIO4: c4 00 4b 46 7f ff 0c 10 06 : crc=06 YES

2020.12.01 09:37:07 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Dachboden)
2020.12.01 09:37:08 1: GPIO4: 5d 00 4b 46 7f ff 0c 10 a9 : crc=a9 YES

2020.12.01 09:37:08 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Spielzimmer)
2020.12.01 09:37:09 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/58_GPIO4.pm line 212, <DATA> line 1.
2020.12.01 09:37:09 1: GPIO4: 44 01 4b 46 7f ff 0c 10 a9 : crc=a9 YES

2020.12.01 09:37:09 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Drempel_Bad)
2020.12.01 09:37:09 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/58_GPIO4.pm line 210.
2020.12.01 09:37:09 1: GPIO4:
2020.12.01 09:37:10 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/58_GPIO4.pm line 212.
2020.12.01 09:37:11 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_K1)
2020.12.01 09:37:12 1: GPIO4: 2a 01 4b 46 7f ff 0c 10 f1 : crc=f1 YES

2020.12.01 09:37:13 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Bad_oben)
2020.12.01 09:37:13 1: GPIO4: 2a 01 4b 46 7f ff 0c 10 f1 : crc=f1 YES

2020.12.01 09:37:14 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Drempel_Strasse)
2020.12.01 09:37:15 1: GPIO4: f6 00 4b 46 7f ff 0c 10 7c : crc=7c YES


Also ist doch nichts in <DATA> vorhanden?

Wenn ich es auf der Console mache:


root@server:~# cat /sys/bus/w1/devices/28*/w1_slave
5e 00 4b 46 7f ff 0c 10 6c : crc=6c YES
5e 00 4b 46 7f ff 0c 10 6c t=5875
f5 00 4b 46 7f ff 0c 10 b9 : crc=b9 YES
f5 00 4b 46 7f ff 0c 10 b9 t=15312
2b 01 4b 46 7f ff 0c 10 b2 : crc=b2 YES
2b 01 4b 46 7f ff 0c 10 b2 t=18687
2b 01 4b 46 7f ff 0c 10 b2 : crc=b2 YES
2b 01 4b 46 7f ff 0c 10 b2 t=18687
13 01 4b 46 7f ff 0c 10 64 : crc=64 YES
13 01 4b 46 7f ff 0c 10 64 t=17187
4d 01 4b 46 7f ff 0c 10 c0 : crc=c0 YES
4d 01 4b 46 7f ff 0c 10 c0 t=20812
25 01 4b 46 7f ff 0c 10 0b : crc=0b YES
25 01 4b 46 7f ff 0c 10 0b t=18312
0c 01 4b 46 7f ff 0c 10 ca : crc=ca YES
0c 01 4b 46 7f ff 0c 10 ca t=16750
c9 00 4b 46 7f ff 0c 10 7a : crc=7a YES
c9 00 4b 46 7f ff 0c 10 7a t=12562
16 02 4b 46 7f ff 0c 10 75 : crc=75 YES
16 02 4b 46 7f ff 0c 10 75 t=33375

Also alles gut. Genauso wie in der alten Version des Moduls. Da habe ich ja auch keine Fehler.

Seltsam. Verstehe ich nicht...bitte auch nicht falsch verstehen! Ich finde den Ansatz das Nonblocking zu gestalten super!

ZitatKansst Du testweise zurück auf den 3er ?
Ja. Relativ problemlos. Lässt sich recht schnell umschrauben. Muss nachher nur noch eine neue SD-Karte besorgen, damit ich mir nichts im jetzigen System zerschieße.
Eigentlich sollte mein neues Image doch 1:1 auch auf dem 3er laufen...oder?

Ich habe mir wohl mit dem Upgrade des Raspberrys keinen Gefallen getan  ::) Die Funkprobleme aus dem anderen Thread sind viel schlimmer.

Danke!

Gruß
Bismosa
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 01 Dezember 2020, 10:28:21
ZitatAlso ist doch nichts in <DATA> vorhanden?
Naja, Du fängst jetzt nicht mehr das fehlgeschlagene open ab.(warum auch immer es fehlschlägt. Rpi4 ?)
den2020.12.01 09:36:08 1: GPIO4: GPIO4_Poll(GPIO4_DS18B20_Spielzimmer)
2020.12.01 09:36:09 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/58_GPIO4.pm line 212, <DATA> line 1.
2020.12.01 09:36:09 1: GPIO4: 43 01 4b 46 7f ff 0c 10 79 : crc=79 YES
finde ich da gerade viel spannender. Verstehe da das Warning nicht.  :-[ Muss ich mir gegen Abend mal näher betrachten.(Versteh gerade überhaupt die ganze Abfolge nicht: device,warning,Dein_neues_Logging  :-\)
Zitatbitte auch nicht falsch verstehen! Ich finde den Ansatz das Nonblocking zu gestalten super!
Keine Sorge. Mit dem non-blocking hat das wenig zu tun.
Grüße Markus
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: bismosa am 01 Dezember 2020, 10:47:50
Hallo!

Zitat von: KölnSolar am 01 Dezember 2020, 10:28:21
Naja, Du fängst jetzt nicht mehr das fehlgeschlagene open ab.(warum auch immer es fehlschlägt. Rpi4 ?)
Darum sollte es jetzt auch erstmal nicht gehen. Ich wollte nur mal loggen, was denn wirklich ausgelesen wird.
Ja. Es handelt sich um einen Rpi4. Werde nachher aber den Rpi3 wieder installieren und schauen, ob meine Probleme dadurch weniger werden.

Danke.

Gruß
Bismosa
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: bismosa am 01 Dezember 2020, 19:06:55
Hallo!

Kleines Update. Ich habe nun wieder den RPI3 komplett laufen. Mit dem neu installierten "Buster" Image.
Der "Fehler" passiert bei mir auch auf dem RPI3. Gleiches verhalten wie auf dem RPI4.

Liegt bestimmt auch an den billigen Sensoren. Die sind vermutlich nicht so ganz ok. Also bitte nicht zu viel Zeit da investieren.

Danke!

Gruß
Bismosa
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 01 Dezember 2020, 21:56:55
was sagt dmesg ? immer wieder disconnects oder ist der bus stabil ?
parasitär oder separate Spannungsversorgung ?
Grüße Markus
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: bismosa am 02 Dezember 2020, 16:06:21
Hallo!
In dmesg derzeit keine Auffälligkeiten.
Separate Spannungsversorgung (5V)
Alle verwendeten Kabel sind Netzwerkkabel.

Da ich zwei "Stränge" habe, habe ich diese vor einiger Zeit mal aufgeteilt und nutze 2 1-Wire Busse

#2.1-Wire bus GPIO17 - Header Pin 11
dtoverlay=w1-gpio,gpiopin=17


Alle paar Tage habe ich mal ein "problem" auf dem einen Bus. Dann kann ich keine Sensoren mehr auslesen...so lange, bis ich einmal die Spannungsversorgung am 1-Wire Bus entferne. Danach klappt es dann sofort wieder.
Von diesem Problem liest man häufiger. Ich schalte die Spannungsversorgung über einen Transistor und einem GPIO-Port. Meldet ein Sensor mehr als 30 Fehler wird die Spannungsversorgung kurz gekappt und die Fehler zurückgesetzt. Dann läuft es wieder für einige Tage stabil.

Gruß
Bismosa
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 02 Dezember 2020, 19:57:23
ZitatVon diesem Problem liest man häufiger. Ich schalte die Spannungsversorgung über einen Transistor und einem GPIO-Port. Meldet ein Sensor mehr als 30 Fehler wird die Spannungsversorgung kurz gekappt und die Fehler zurückgesetzt. Dann läuft es wieder für einige Tage stabil.
Interessant

ZitatDa ich zwei "Stränge" habe, habe ich diese vor einiger Zeit mal aufgeteilt und nutze 2 1-Wire Busse
Ob das das Problem ist ?  :-\

Grüße Markus
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: bismosa am 02 Dezember 2020, 21:14:08
Hallo!

Ich weiß es nicht. Vielleicht habe ich ja mal irgendwann genug Zeit und lust die Sensoren zu tauschen...das wird aber eher ein längerfristiges Projekt. Da kommt man kaum dran.
Witzigerweise funktioniert es ja mit der "alten" Version des Moduls aus dem Ordner "contrib".
Aber ich sehe auch selbst, dass es eigentlich gar keinen Grund gibt, warum es bei Deiner Version nicht gehen sollte. Es ist ja die gleiche Funktion die aufgerufen wird.

Vielleicht habe ich die Tage ja noch ne Idee, wie ich das anders debuggen könnte. Durch den Wechsel zurück auf den RPI3 schlage ich mich hier gerade wieder mit anderen Problemen rum  ::) (Jetzt stürzt mein Netzwerk wieder häufig ab, sobald etwas mehr Datenverkehr stattfindet...das war einer der Gründe warum ich auf den RPI4 wechseln wollte.)

Gruß
Bismosa
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: Wernieman am 05 Dezember 2020, 15:20:41
Ethernet oder WLAN?

So etwas habe ich bei Ethernet (LAN) beim Pi noch nie gehabt ....
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 05 Dezember 2020, 21:08:19
ZitatWitzigerweise funktioniert es ja mit der "alten" Version des Moduls aus dem Ordner "contrib".
Müsste ich glatt mal gucken, worin sich die Module unterscheiden. Mein non-blocking setzte ja nicht auf der contrib-Version, sondern der x-ten Folgeversion auf.
Grüße Markus
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: bismosa am 12 Januar 2021, 18:25:37
Hallo!

Ich habe mich heute mal wieder mit dem Problem beschäftigt. Auch auf einem Pi3 läuft es bei mir nicht.
Ich habe mal aus der Blocking.pm das Beispiel etwas umgestrickt um zu testen, ob es daran liegt. Das ganze dann in die myUtils übernommen:
sub TestBlocking($){ BlockingCall("DoSleep", shift, "SleepDone", 5, "AbortFn", "AbortArg"); }
sub DoSleep($)     {
my $dev = shift;
open DATA, "/sys/bus/w1/devices/$dev/w1_slave";
if (<DATA>=~ /YES/) {
return "$dev ok";
} else {
return "$dev nicht ok";
}
}
sub SleepDone($)   { Log 1, "SleepDone: " . shift; }
sub AbortFn($)     { Log 1, "Aborted: " . shift; }

sub startPoll(){
TestBlocking("28-01143bb82baa");
TestBlocking("28-01143b91f4aa");
TestBlocking("28-01143beb36aa");
TestBlocking("28-01143b97ecaa");
TestBlocking("28-041636495aff");
TestBlocking("28-0416367be4ff");
TestBlocking("28-01143beb9aaa");
TestBlocking("28-01143b98f5aa");
TestBlocking("28-01143bf065aa");
TestBlocking("28-0316363035ff");
}

Auch hier tritt der Fehler bei mir auf. Im Log habe ich dann so etwas:

2021.01.12 17:25:44 1: SleepDone: 28-01143bb82baa ok
2021.01.12 17:25:44 1: SleepDone: 28-01143b91f4aa ok
2021.01.12 17:25:44 1: SleepDone: 28-01143beb36aa ok
2021.01.12 17:25:44 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/99_myUtils.pm line 1973.
2021.01.12 17:25:44 3: eval: {startPoll}
2021.01.12 17:25:44 1: SleepDone: 28-01143b98f5aa nicht ok
2021.01.12 17:25:44 1: SleepDone: 28-01143b97ecaa ok
2021.01.12 17:25:45 1: SleepDone: 28-041636495aff ok
2021.01.12 17:25:45 1: SleepDone: 28-0416367be4ff ok
2021.01.12 17:25:45 1: SleepDone: 28-01143beb9aaa ok
2021.01.12 17:25:45 1: SleepDone: 28-01143bf065aa ok
2021.01.12 17:25:45 1: SleepDone: 28-0316363035ff ok

Immer mal wieder bei anderen Sensoren. Gelegentlich auch ohne Problem.

Wenn ich die Sensoren ohne BlockingCall auslese, klappt es immer problemlos:

sub startPoll2(){
Log 1, DoSleep("28-01143bb82baa");
Log 1, DoSleep("28-01143b91f4aa");
Log 1, DoSleep("28-01143beb36aa");
Log 1, DoSleep("28-01143b97ecaa");
Log 1, DoSleep("28-041636495aff");
Log 1, DoSleep("28-0416367be4ff");
Log 1, DoSleep("28-01143beb9aaa");
Log 1, DoSleep("28-01143b98f5aa");
Log 1, DoSleep("28-01143bf065aa");
Log 1, DoSleep("28-0316363035ff");
return "ok"
}

Log:

2021.01.12 17:29:17 1: 28-01143bb82baa ok
2021.01.12 17:29:17 1: 28-01143b91f4aa ok
2021.01.12 17:29:18 1: 28-01143beb36aa ok
2021.01.12 17:29:19 1: 28-01143b97ecaa ok
2021.01.12 17:29:20 1: 28-041636495aff ok
2021.01.12 17:29:21 1: 28-0416367be4ff ok
2021.01.12 17:29:22 1: 28-01143beb9aaa ok
2021.01.12 17:29:23 1: 28-01143b98f5aa ok
2021.01.12 17:29:24 1: 28-01143bf065aa ok
2021.01.12 17:29:24 1: 28-0316363035ff ok


Also liegt es ganz klar am BlockingCall. Keine Ahnung, was da genau anders ist.
Ich habe es auch probiert, indem ich mit dem Befehl "cat" auslese:
my $DATA=`cat /sys/bus/w1/devices/$dev/w1_slave`;
Das macht aber keinen Unterschied.

Was mir auffällt ist die Auslesezeit. Die ist bei parallelem Aufruf viel schneller. Kommt vielleicht dadurch das System durcheinander?

Ich habe nun meine beiden Busse auf einen umverdrahtet. Hier das gleiche. Es kann also nur an den vielleicht zu langsamen Sensoren in dieser Kombination liegen.

Vielleicht weiß ja jemand, was genau im BlockingCall bei Systemaufrufen anders ist. Gibt es da vielleicht einen Timeout?

Gruß
Bismosa
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 12 Januar 2021, 20:18:44
Hi,
ZitatVielleicht weiß ja jemand, was genau im BlockingCall bei Systemaufrufen anders ist
Anders ist da nichts. Und komischerweise bist Du der Erste u. Einzige, der solche Probleme hat.
Eigentlich ist leicht erklärt, was da passiert: Im "Normalfall" löst das read(oder das open ?) die Temperaturmessung aus. Die dauert aber bei 1W(je nach precision) über 1s. Daher hab ich das in den BlockingCall gepackt, so dass FHEM weiterläuft und der lähmende Teil parallel läuft. Ist der fertig, gibt er das Ergebnis wieder an FHEM zurück, welches dann in readings umgewandelt wird.

Ich kann mir nach wie vor keinen Reim drauf machen. Oder doch: Wie ist der pollingmode eingestellt ? Könnten sich da 2 BlockingCalls für EINEN Sensor ins Gehege kommen ?

Kannst Du vielleicht nochmal kurz die Symptomatik zusammenfassen(also ohne Lösungsversuche). Ich hab irgendwie den Überblick verloren.

Grüße Markus
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: bismosa am 13 Januar 2021, 08:31:59
Hallo!

ZitatUnd komischerweise bist Du der Erste u. Einzige, der solche Probleme hat.
Ja...manchmal fange ich auch an zu zweifeln. Ich habe vielleicht auch einfach ein bisschen mehr als der Durchschnittsuser auf dem Raspi laufen  :)

ZitatIch kann mir nach wie vor keinen Reim drauf machen. Oder doch: Wie ist der pollingmode eingestellt ? Könnten sich da 2 BlockingCalls für EINEN Sensor ins Gehege kommen ?
Pollingmode ist nichts eingestellt. Auch kein Intervall. Also sollte der Standardintervall verwendet werden.

ZitatKannst Du vielleicht nochmal kurz die Symptomatik zusammenfassen(also ohne Lösungsversuche). Ich hab irgendwie den Überblick verloren.
Gerne. Sorry, das ich da so konfus bin.

Ich habe 10 DS18b20 Sensoren. Alles billige Chinaware. Verkabelt über Netzwerkkabel mit eigener Stromversorgung.
Nutze ich das "alte" Modul zum auslesen der Sensoren funktioniert alles fast problemlos.
(Warum fast problemlos: Alle paar Tage kommt es zu lesefehlern auf dem Bus. Vermutlich hängt sich einer der Sensoren auf. In dem Fall trenne ich die Stromversorgung der Sensoren kurz. Danach funktioniert wieder alles problemlos)
Erst mit dem neuen Modul kommt es sehr häufig zu lesefehlen.

Um das nachzustellen und ein Problem des Moduls auszuschließen habe ich es in den myUtils mal nachgestellt die Sensoren auf unterschiedliche Arten auszulesen:
1.) Wie im alten Modul als blockierender Aufruf -> Keine Lesefehler
2.) Wie im neuen Modul als BlockingCall -> Lesefehler
Somit ist klar, dass es nicht am Modul selbst liegt, sondern am BlockingCall.

Mach Dir bitte keinen Streß deswegen. Ich muss wohl einfach mal ne neue Charge Sensoren kaufen und mir den Tag Zeit nehmen um die neu zu verkabeln. Vielleicht ist dann das Problem auch Geschichte  :)

Gruß
Bismosa
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 13 Januar 2021, 12:09:51
ZitatJa...manchmal fange ich auch an zu zweifeln. Ich habe vielleicht auch einfach ein bisschen mehr als der Durchschnittsuser auf dem Raspi laufen
Lass mal die Zweifel. Ich hab just heute im Log gesehen, dass ich auch ab und an Perl warnings aus Zeile 211 bekomme. ::) Komischerweise, wo ich in einem anderen Modul(auch blockingCall) einige Perl warnings bekommen habe. Irgendwie drängt sich der Verdacht auf, dass es entweder die Anzahl der blockingCalls(davor wird ja bei Verwendung von BlockinCall gewarnt) ist oder die hohe Systemlast.

Was läuft denn bei Dir noch so mit häufigen BlockingCalls ?
Hattest Du nicht auch freezes gemeldet ?

Ich hab mal den Fehler abgefangen. Dann kommt wenigstens(hoffentlich) keine perl warning mehr. Dafür aber ein "erwünschter" Log-Eintrag zum Fehler. Außerdem wird der Fehler nun auch als solcher gezählt und ein neues reading "failreason" angelegt. Vielleicht bekommen wir über Statistik ein Gefühl, warum das passiert. Sobald bei mir mal ein Fehler auftaucht, attache ich hier die Version.

Grüße Markus
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: bismosa am 13 Januar 2021, 13:10:26
Hallo!

ZitatWas läuft denn bei Dir noch so mit häufigen BlockingCalls ?
Hattest Du nicht auch freezes gemeldet ?
Hauptfreeze ist bei mir das GPIO4. Das ist zumindest sehr auffällig. Deswegen möchte ich das auch nach Möglichkeit beseitigen.  :)
Es läuft halt recht viel...was da jetzt im Blocking-Call läuft...keine Ahnung.

Nur mal so als Idee:
Es werden alle Sensoren gleichzeitig abgefragt (und nicht mehr nacheinander). Vielleicht muss man eine zeitliche Verzögerung einbauen, damit für den BUS genug Zeit ist um alle Sensoren abzufragen.?
Ich probier das nachher mal aus, ob sich dann etwas ändert.

Gruß
Bismosa
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 13 Januar 2021, 20:27:07
ZitatEs werden alle Sensoren gleichzeitig abgefragt (und nicht mehr nacheinander).
Neinnein. Da hat sich nichts geändert. Jedes device hat sein eigenes polling interval. Wenn Du das Attribut nicht setzt, ist der Standard 60.

Ich häng jetzt mal die Testversion an, da sie bei mir seit ein einem halben Tag läuft u. ich Logmeldungen des neuen features bekam, das daran liegt, dass ein Sensor gar nicht angeschlossen ist. und tatsächlich einmal einen read failure. Der open/read Fehler erscheint im Log u. als reading. Der failure counter wird hochgezählt. Scheint also ganz hilfreich.  ;)

Grüße Markus
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: bismosa am 14 Januar 2021, 11:50:33
Hallo!

ZitatNeinnein. Da hat sich nichts geändert.
Doch ich glaube schon. Wenn ich das richtig verstanden habe funktioniert das in etwa so: (Sorry...eigentlich habe ich keine Ahnung)
Beim starten von FHEM werden alle Definitionen geladen und die Timer zum aktualisieren gesetzt. Vermutlich alle innerhalb einer Sekunde.
Also kommt es beim Polling zu einer Überschneidung.

Durch das lesen des Files wird der eigentliche Sensor abgefragt. Daher auch die Verzögerung.
Alter weg:
Sensor1 wird abgefragt...dies dauert 1-2sek. (Fhem blockiert)...wert wird übernommen
Sensor2 wird abgefragt...dies dauert 1-2sek. (Fhem blockiert)...wert wird übernommen
Neuer weg:
Jeder Sensor wird in einem eigenem "Thread/Prozess" (Sorry, ich programmiere hauptsächlich in Windows) abgefragt. Es kommt nicht zum blocking von FHEM, also werden ggf. mehrere Sensoren zur gleichen Zeit abgefragt.

Siehe auch mein vereinfachtes Beispiel. Frage ich alle nacheinander non-Blocking ab, erhalte ich eine Antwort innerhalb von 2-3sek für alle. Bei einer blockierenden Abfrage dauert es 7sek. bis alle Werte verfügbar sind.

Ich habe mal einen Test in einem Bash-Script gemacht:

cat /sys/bus/w1/devices/28-01143b91f4aa/w1_slave &
cat /sys/bus/w1/devices/28-01143b98f5aa/w1_slave &
cat /sys/bus/w1/devices/28-01143beb36aa/w1_slave &
cat /sys/bus/w1/devices/28-01143bf065aa/w1_slave &
cat /sys/bus/w1/devices/28-041636495aff/w1_slave &
cat /sys/bus/w1/devices/28-01143b97ecaa/w1_slave &
cat /sys/bus/w1/devices/28-01143bb82baa/w1_slave &
cat /sys/bus/w1/devices/28-01143beb9aaa/w1_slave &
cat /sys/bus/w1/devices/28-0316363035ff/w1_slave &
cat /sys/bus/w1/devices/28-0416367be4ff/w1_slave &

So werden bei mir alle Sensoren gleichzeitig/Parallel abgefragt. Und auch hier passiert es, dass einzelne Sensoren nichts melden.
Frage ich die nacheinander ab (ohne "&"), gibt es das Problem nicht.

Ich könnte auch das einfach von FHEM abkoppeln mit einem Bash-Script...das nutze ich bei i2c mit meinen Analogen Sensoren auch. Aber ich bin auch an einer Lösung hier interessiert  ;)

Modul teste ich später. Schaffe das gerade zeitlich nicht  :)

Gruß
Bismosa
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 14 Januar 2021, 16:21:56
ZitatDoch ich glaube schon. Wenn ich das richtig verstanden habe funktioniert das in etwa so: (Sorry...eigentlich habe ich keine Ahnung)
Beim starten von FHEM werden alle Definitionen geladen und die Timer zum aktualisieren gesetzt. Vermutlich alle innerhalb einer Sekunde.
Also kommt es beim Polling zu einer Überschneidung.
Da hast Du recht. Und vielleicht ist das der Grund, warum ich keine Probleme habe. Ich hab ja unterschiedliche Intervalle gesetzt.

Ich hab mal etwas umgebaut. Dadurch müsste sich das über die Zeit entzerren, weil der timer durch Systemverzögerungen sich immer mehr auseinanderschieben müsste.

Was mir beim Studium des Codes auch noch in den Sinn gekommen ist: rein theoretisch könnte es passieren, dass der letzte Call gerade läuft und nun der neue Call(60s später) erst einmal prüft, ob es den letzten noch gibt. Wenn ja, wird der letzte gekilled.

Schauen wir mal.

Markus
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: Wernieman am 14 Januar 2021, 18:45:53
Eigentlich müstest Du eine Pipeline haben. Also praktisch ein Device, was alle Calls abarbeitet, aber eben "nacheinander". Diese Pipeline wird durch die Timer befüllt. Wenn leer = Sofortige Abarbeitung. Wenn schon was "drinsteht" eben später ... so das wirklich nur eine Abfrage zur zeit laufen kann ..,.
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 14 Januar 2021, 20:23:53
Ab FHEM Revision 11917 lassen sich die maximal parallel laufenden BlockingCalls durch das globale Attribut blockingCallMax begrenzen (Standardwert: unbegrenzt). Sofern die maximale parallele Anzahl an BlockingCalls erreicht ist, werden weitere Calls in eine Warteschlange eingereiht und ausgeführt, sobald laufende Calls beendet werden.Wäre dann die Lösung.
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: Wernieman am 15 Januar 2021, 07:57:13
Damit blockst Du aber docha lle BlockingCalls ... d.h. wenn Du zusätzlich ein anderes Modul damit verwendest ...
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: bismosa am 15 Januar 2021, 09:34:16
Hallo!

Erstmal: DANKE, das ihr euch mit meinem Problem beschäftigt!

ZitatIch hab mal etwas umgebaut. Dadurch müsste sich das über die Zeit entzerren, weil der timer durch Systemverzögerungen sich immer mehr auseinanderschieben müsste.
Habe ich ausprobiert. Tatsächlich verschiebt sich die Ausführung...aber das Problem bleibt bei mir bestehen. So sieht es dann in der Log-Datei aus:
2021.01.14 18:08:56 2: GPIO4: GPIO4_DS18B20_Bad_oben of family 28 and id 01143bb82baa with failure read_failure
2021.01.14 18:08:56 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 18:11:02 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 18:12:04 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 18:15:07 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 18:21:14 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 18:28:22 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 18:30:25 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 18:42:40 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 18:49:48 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 18:51:50 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 18:52:51 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 19:30:36 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 19:31:37 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 19:36:44 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 19:42:51 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 19:45:54 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 19:47:56 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 19:48:58 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 19:49:59 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 19:51:00 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 19:55:05 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 19:56:06 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 19:59:16 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:05:23 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:06:24 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:07:25 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:11:30 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:12:31 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:16:36 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:17:42 2: GPIO4: GPIO4_DS18B20_Bad_oben of family 28 and id 01143bb82baa with failure read_failure
2021.01.14 20:17:43 2: GPIO4: GPIO4_DS18B20_Drempel_Bad of family 28 and id 01143beb36aa with failure read_failure
2021.01.14 20:17:43 2: GPIO4: GPIO4_DS18B20_Tamara of family 28 and id 01143b98f5aa with failure read_failure
2021.01.14 20:18:43 2: GPIO4: GPIO4_DS18B20_Bad_oben of family 28 and id 01143bb82baa with failure read_failure
2021.01.14 20:19:45 2: GPIO4: GPIO4_DS18B20_Drempel_Bad of family 28 and id 01143beb36aa with failure read_failure
2021.01.14 20:21:49 2: GPIO4: GPIO4_DS18B20_Tamara of family 28 and id 01143b98f5aa with failure read_failure
2021.01.14 20:21:50 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:22:51 2: GPIO4: GPIO4_DS18B20_Tamara of family 28 and id 01143b98f5aa with failure read_failure
2021.01.14 20:22:51 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:23:52 2: GPIO4: GPIO4_DS18B20_Tamara of family 28 and id 01143b98f5aa with failure read_failure
2021.01.14 20:23:52 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:24:53 2: GPIO4: GPIO4_DS18B20_Tamara of family 28 and id 01143b98f5aa with failure read_failure
2021.01.14 20:25:54 2: GPIO4: GPIO4_DS18B20_Drempel_Bad of family 28 and id 01143beb36aa with failure read_failure
2021.01.14 20:25:54 2: GPIO4: GPIO4_DS18B20_Tamara of family 28 and id 01143b98f5aa with failure read_failure
2021.01.14 20:26:55 2: GPIO4: GPIO4_DS18B20_Tamara of family 28 and id 01143b98f5aa with failure read_failure
2021.01.14 20:26:56 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:27:57 2: GPIO4: GPIO4_DS18B20_Tamara of family 28 and id 01143b98f5aa with failure read_failure
2021.01.14 20:27:57 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:28:58 2: GPIO4: GPIO4_DS18B20_Tamara of family 28 and id 01143b98f5aa with failure read_failure
2021.01.14 20:28:58 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:29:59 2: GPIO4: GPIO4_DS18B20_Tamara of family 28 and id 01143b98f5aa with failure read_failure
2021.01.14 20:29:59 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:31:01 2: GPIO4: GPIO4_DS18B20_Tamara of family 28 and id 01143b98f5aa with failure read_failure
2021.01.14 20:31:01 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:32:02 2: GPIO4: GPIO4_DS18B20_Tamara of family 28 and id 01143b98f5aa with failure read_failure
2021.01.14 20:32:02 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:33:03 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:34:04 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:35:05 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:36:07 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:37:08 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:38:09 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:39:10 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:42:14 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:43:15 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.14 20:44:17 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure

Erstaunlich oft der Dachboden. Ob hier vielleicht ein defekter Sensor ist? Oder das Kabel zu lang ist?

Ich habe parallel versucht das Modul umzustricken, das nur ein Aufruf gleichzeitig erfolgt. Leider sind meine Perl-Kentnisse nicht so gut...ich vermute ich habe beim DeviceSpec noch einen Wurm drin.
Ich setze ein Internal kurz vor Aufruf des BlockingCall:
$hash->{RUNSTATE}="running";
$hash->{helper}{RUNNING_PID} = BlockingCall("GPIO4_Poll", $hash,"GPIO4_GetfinishFn");

In "sub GPIO4_Poll($) {"

my $return_array = "$hash->{NAME}|$family|$id";
Log 6, "GPIO4: GPIO4_Poll($hash->{NAME})";
my @devicesRun = devspec2array("TYPE=GPIO4 Filter=RUNSTATE=running");
while(scalar(@devicesRun) !=0){
Log 6, "GPIO4: Wait for other to finish ".join( '-', @devicesRun);
sleep 1;
@devicesRun = devspec2array("TYPE=GPIO4 Filter=RUNSTATE=running");
}

Und in "sub GPIO4_GetfinishFn($) {"

my @return_array = split("\\|",$string);
my $hash = $defs{$return_array[0]};
$hash->{RUNSTATE}="ready";


Das wäre (nach Korrektur) vielleicht ein Weg, um immer nur ein Device zur gleichen Zeit abzufragen. Wird eins gerade abgefragt, wird so lange gewartet, bis dies fertig ist.

ZitatAb FHEM Revision 11917 lassen sich die maximal parallel laufenden BlockingCalls durch das globale Attribut blockingCallMax begrenzen
ZitatDamit blockst Du aber docha lle BlockingCalls ... d.h. wenn Du zusätzlich ein anderes Modul damit verwendest ...
Das hatte ich gestern auch noch entdeckt. Bei mir läuft gerade der erste Versuch mit  blockingCallMax = 1 (Seit 30Min mit bisher nur einem Log-Eintrag)
Es werden keine Calls geblockt. Diese werden nur nacheinander ausgeführt (Warteschlange).

Also könnte tatsächlich ein warten auf laufende Abfragen abhilfe schaffen. Mal schauen, ob ich heute Nachmittag den Fehler noch finde  :)

Gruß
Bismosa
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 15 Januar 2021, 12:24:07
ZitatDamit blockst Du aber docha lle BlockingCalls ... d.h. wenn Du zusätzlich ein anderes Modul damit verwendest ...
Das stimmt. Aber besser es dauert ein wenig, als dass es zu Fehlern führt. Anwendungen mit BlockingCall dürften selten zeitkritisch sein. Und wir haben es hier mit einem Einzelfall zu tun, den es erst einmal nur "zu verstehen" gilt.
ZitatErstaunlich oft der Dachboden. Ob hier vielleicht ein defekter Sensor ist? Oder das Kabel zu lang ist?
Alles möglich. Vielleicht braucht der länger beim messen ?  :-\ Wie ich schon sagte, mit der neuen Version bekommen wir etwas mehr Statistik. Möglicherweise ergibt sich daraus ja eine Erkenntnis(bei mir ist mal wieder seit 24h völlige Ruhe)
ZitatDas wäre (nach Korrektur) vielleicht ein Weg, um immer nur ein Device zur gleichen Zeit abzufragen. Wird eins gerade abgefragt, wird so lange gewartet, bis dies fertig ist.
Nicht wirklich. Das sleep konterkarriert ja das BlockingCall. Da scheint mir BlockingCallMax die bessere Variante(sofern es nicht auch blockierend funktioniert). Zumindest um einfach das Problem zu analysieren.
ZitatErstaunlich oft der Dachboden
Vermutlich doch ein relativ unwichtiger Wert. Setz den doch mal auf pollinginterval 301.  ;)

Vielleicht nochmal zum Vergleich mein System: 12 Sensoren, davon die meisten mit standardpollingintervall, 2-3 mit mittlerem Intervall und einer mit nur 5s. Um die events einzudämmen alle mit "event-on-change-reading temperature:x" u. x=angemessener Wert . Auf einem Rpi3 der als lokaler DNS mit pi-hole fungiert. Mehr läuft da nicht drauf.

Grüße Markus



Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: bismosa am 15 Januar 2021, 20:10:37
Hallo!

Ich bin etwas weiter...aber der Lösung leider nicht wirklich näher gekommen.

Mit
blockingCallMax = 1
Gab es weiterhin (aber nur extrem wenige) Lesefehler. (Insgesamt 4x nach mehreren Stunden).
Allerdings gab es bei jedem Neustart Fehler.

Ich habe es dann mit meiner Modulinternen Lösung weiter probiert. Siehe Anhang.
Dies läuft ja auch vollständig Non-Blocking, da während des Blocking-Call gewartet wird. Mein Log sieht nach einem Neustart dann recht witzig aus (Hatte das noch auf Verbose 1):

2021.01.15 19:40:18 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Werkstatt
2021.01.15 19:40:18 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:40:19 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:40:19 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:40:20 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Tamara-GPIO4_DS18B20_Werkstatt
2021.01.15 19:40:20 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Tamara
2021.01.15 19:40:22 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Spielzimmer-GPIO4_DS18B20_Tamara
2021.01.15 19:40:22 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Spielzimmer-GPIO4_DS18B20_Tamara
2021.01.15 19:40:22 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse-GPIO4_DS18B20_Spielzimmer-GPIO4_DS18B20_Tamara
2021.01.15 19:40:22 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse-GPIO4_DS18B20_Spielzimmer-GPIO4_DS18B20_Tamara-GPIO4_DS18B20_Thekla
2021.01.15 19:40:24 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.15 19:41:21 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Werkstatt
2021.01.15 19:41:21 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:41:22 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:41:22 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:41:23 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Tamara-GPIO4_DS18B20_Werkstatt
2021.01.15 19:41:23 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Tamara
2021.01.15 19:41:24 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Tamara
2021.01.15 19:41:24 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Spielzimmer-GPIO4_DS18B20_Tamara
2021.01.15 19:41:25 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse-GPIO4_DS18B20_Spielzimmer-GPIO4_DS18B20_Tamara
2021.01.15 19:41:26 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse-GPIO4_DS18B20_Spielzimmer-GPIO4_DS18B20_Thekla
2021.01.15 19:41:27 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.15 19:42:23 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Werkstatt
2021.01.15 19:42:24 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:42:25 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:42:25 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:42:26 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Tamara-GPIO4_DS18B20_Werkstatt
2021.01.15 19:42:26 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Tamara
2021.01.15 19:42:27 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Tamara
2021.01.15 19:42:28 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Spielzimmer-GPIO4_DS18B20_Tamara
2021.01.15 19:42:28 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse-GPIO4_DS18B20_Spielzimmer-GPIO4_DS18B20_Tamara
2021.01.15 19:42:28 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse-GPIO4_DS18B20_Spielzimmer-GPIO4_DS18B20_Thekla
2021.01.15 19:42:30 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.15 19:43:26 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Werkstatt
2021.01.15 19:43:27 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:43:28 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:43:28 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:43:29 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Tamara-GPIO4_DS18B20_Werkstatt
2021.01.15 19:43:29 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Tamara
2021.01.15 19:43:30 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Tamara
2021.01.15 19:43:31 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Spielzimmer
2021.01.15 19:43:31 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse-GPIO4_DS18B20_Spielzimmer
2021.01.15 19:43:32 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse-GPIO4_DS18B20_Spielzimmer-GPIO4_DS18B20_Thekla
2021.01.15 19:43:32 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.15 19:44:29 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Werkstatt
2021.01.15 19:44:29 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:44:30 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:44:31 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:44:31 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Tamara-GPIO4_DS18B20_Werkstatt
2021.01.15 19:44:31 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Tamara
2021.01.15 19:44:33 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Tamara
2021.01.15 19:44:34 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Spielzimmer
2021.01.15 19:44:34 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse-GPIO4_DS18B20_Spielzimmer
2021.01.15 19:44:34 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse-GPIO4_DS18B20_Spielzimmer-GPIO4_DS18B20_Thekla
2021.01.15 19:45:31 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Werkstatt
2021.01.15 19:45:32 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:45:32 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:45:33 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:45:33 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Tamara-GPIO4_DS18B20_Werkstatt
2021.01.15 19:45:33 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Tamara
2021.01.15 19:45:35 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Tamara
2021.01.15 19:45:36 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse
2021.01.15 19:45:36 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse-GPIO4_DS18B20_Spielzimmer
2021.01.15 19:45:36 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse-GPIO4_DS18B20_Spielzimmer-GPIO4_DS18B20_Thekla
2021.01.15 19:45:37 2: GPIO4: GPIO4_DS18B20_Dachboden of family 28 and id 01143b91f4aa with failure read_failure
2021.01.15 19:46:33 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Werkstatt
2021.01.15 19:46:34 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:46:34 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:46:35 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:46:35 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Tamara-GPIO4_DS18B20_Werkstatt
2021.01.15 19:46:36 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Tamara
2021.01.15 19:46:37 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Tamara
2021.01.15 19:46:38 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse
2021.01.15 19:46:38 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse-GPIO4_DS18B20_Spielzimmer
2021.01.15 19:46:38 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse-GPIO4_DS18B20_Spielzimmer-GPIO4_DS18B20_Thekla
2021.01.15 19:47:35 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Werkstatt
2021.01.15 19:47:36 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:47:36 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:47:37 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:47:37 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Tamara-GPIO4_DS18B20_Werkstatt
2021.01.15 19:47:38 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Tamara
2021.01.15 19:47:39 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Tamara
2021.01.15 19:47:40 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse
2021.01.15 19:47:41 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse-GPIO4_DS18B20_Spielzimmer
2021.01.15 19:47:41 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse-GPIO4_DS18B20_Spielzimmer-GPIO4_DS18B20_Thekla
2021.01.15 19:48:37 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Werkstatt
2021.01.15 19:48:38 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:48:39 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:48:39 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Werkstatt
2021.01.15 19:48:39 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Netzteil-GPIO4_DS18B20_Tamara-GPIO4_DS18B20_Werkstatt
2021.01.15 19:48:40 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Drempel_Bad-GPIO4_DS18B20_Kaltwasser-GPIO4_DS18B20_Tamara
2021.01.15 19:48:42 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Bad_oben-GPIO4_DS18B20_Dachboden
2021.01.15 19:48:43 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse
2021.01.15 19:48:43 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse-GPIO4_DS18B20_Spielzimmer
2021.01.15 19:48:44 1: GPIO4: Wait for other to finish GPIO4_DS18B20_Dachboden-GPIO4_DS18B20_Drempel_Strasse-GPIO4_DS18B20_Spielzimmer-GPIO4_DS18B20_Thekla

Aber auch hier gibt es Lesefehler. Auch beim starten von FHEM.
Schade, das bringt uns nicht wirklich voran.

Beim Schreiben habe ich gerade eine Idee...ohne es jetzt weiter geprüft zu haben...
Wie wird die Genauigkeit (Anzahl der Kommastellen) gesetzt? Läuft diese Version mit einer "höheren Genauigkeit"? Ich hatte mal gelesen, das je genauer, desto länger dauert die Datenübertrgaung...
Zitat
Erstaunlich oft der Dachboden
Vermutlich doch ein relativ unwichtiger Wert. Setz den doch mal auf pollinginterval 301.  ;)
Könnte ich machen. Insgesamt brauche ich eh nicht so viele Werte...solange wir testen, werde ich alle erstmal beim Standard belassen.
Ich habe neue Sensoren geordert und werde dann als erstes den auf dem Dachboden tauschen...aber das dauert noch ein paar Tage (bei den Temperaturen vielleicht auch noch etwas länger  ;) )

ZitatMehr läuft da nicht drauf.
Hmmm...ich wüsste jetzt gar nicht, wo ich anfangen soll...die meisten GPIO sind belegt (als GPIO, I2C, 1wire...), 2 HDDs (u.a. für Musik und Backups), Logitech Media Server, FileServer, 433MHz CUL, 868MHz Cul (MAX), Zigbee CUL, >120 DOIFs, >300 FileLog, 113 SVG....
Also mein System wird gut genutzt  ;)

Gruß
Bismosa
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 15 Januar 2021, 20:41:19
ZitatAlso mein System wird gut genutzt  ;)
Ich denke das ist das Problem. Wie sieht denn bei Dir top aus ?(also ich will es nicht sehen  ;D)

ZitatDies läuft ja auch vollständig Non-Blocking, da während des Blocking-Call gewartet wird.
Stimmt. Aber dann müsstest Du ne Menge fork-Prozesse haben.

ZitatGab es weiterhin (aber nur extrem wenige) Lesefehler. (Insgesamt 4x nach mehreren Stunden).
Na wer sagts denn.  ;D Ich vermute dann mal, dass das Problem entsteht, wenn zu viele Prozesse parallel laufen. Vielleicht hat der Prozess des w1-busmasters ja ein Problem damit und killt seine eigene Messung ? :-\ Da könnte vielleicht wirklich die Genauigkeit helfen.

ZitatWie wird die Genauigkeit (Anzahl der Kommastellen) gesetzt? Läuft diese Version mit einer "höheren Genauigkeit"? Ich hatte mal gelesen, das je genauer, desto länger dauert die Datenübertrgaung...
Korrekt. Je genauer, desto länger( > 1s). Grundsätzlich sind die "Dinger" auf höchster Genauigkeit im Auslieferungszustand. Daher hab ich das set precision eingeführt. 9(bit) niedrigste(schnellste) - 12(bit) höchste(langsamste) Genauigkeit(Geschwindigkeit). So geht's. (https://forum.fhem.de/index.php/topic,11142.msg1036391.html#msg1036391)
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: bismosa am 16 Januar 2021, 10:25:14
Hallo!

Zitatie sieht denn bei Dir top aus ?
Ich würde behaupten alles im grünen Bereich. Nur FHEM ist manchmal bei 100% CPU (vermutlich während es auch blockiert)

ZitatStimmt. Aber dann müsstest Du ne Menge fork-Prozesse haben.
ZitatNa wer sagts denn.  ;D Ich vermute dann mal, dass das Problem entsteht, wenn zu viele Prozesse parallel laufen. Vielleicht hat der Prozess des w1-busmasters ja ein Problem damit und killt seine eigene Messung ? :-\ Da könnte vielleicht wirklich die Genauigkeit helfen.
Ja. Jetzt verstehe ich warum meine Idee da nicht so gut ist! Vermutlich gibt es deswegen dann auch die noch häufigen Fehler.

Das hat mich nun aber auf eine andere Idee gebracht. Warum nicht vor dem Start des Blocking-Call prüfen, ob andere gerade ausgelesen werden und den Timer neu setzen? Dann entfallen die Fork-Prozesse und FHEM sollte auch nicht blockieren.

Neue Version ist im Anhang. die läuft jetzt bei mir testweise.
Bisher ist nur 1x ein Fahler aufgetaucht direkt beim starten von FHEM. Das wäre für mich zu vernachlässigen.

Gruß
Bismosa

[edit]
Ich habe nun auch mal den Freezemon wieder aktiviert. Vorher konnte ich mich vor Einträgen kaum retten...nun keine Freezes mehr in GPIO4 (bitte das Datum beachten):

1 - 2020-11-30: s:17:16:05 e:17:16:06 f:1.304 d:tmr-GPIO4_DeviceUpdateLoop(GPIO4_DS18B20_Drempel_Strasse) tmr-SB_SERVER_tcb_SendAlarmPlaylists(LMS) tmr-SB_SERVER_tcb_SendSyncMasters(LMS) tmr-DOIF_TimerTrigger(di_Fenster_Liste) tmr-DOIF_TimerTri...
1 - 2020-11-30: s:17:20:50 e:17:20:51 f:1.972 d:no bad guy found :-(
1 - 2020-11-30: s:17:20:53 e:17:20:55 f:2.452 d:tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-DOIF_SleepTrigger(di_Fen...
1 - 2020-11-30: s:17:20:57 e:17:20:58 f:1.304 d:tmr-sleep_WakeUpFn(N/A)
1 - 2020-11-30: s:17:20:59 e:17:21:00 f:1.793 d:tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A)
1 - 2020-11-30: s:17:21:02 e:17:21:03 f:1.017 d:tmr-GPIO4_DeviceUpdateLoop(GPIO4_DS18B20_Dachboden)
1 - 2020-11-30: s:17:21:04 e:17:21:06 f:2.393 d:tmr-MQTT2_SERVER_keepaliveChecker(MQTT2_FHEM_Server) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A)...
1 - 2020-11-30: s:17:21:07 e:17:21:10 f:3.697 d:tmr-GPIO4_DeviceUpdateLoop(GPIO4_DS18B20_Drempel_Bad) tmr-DOIF_TimerTrigger(di_Fenster_Liste) tmr-DOIF_TimerTrigger(di_Fenster_Liste_ALT_CPULAST) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tm...
1 - 2020-11-30: s:17:21:11 e:17:21:14 f:3.416 d:tmr-at_Exec(at_HeizungGPIO_Test) tmr-sleep_WakeUpFn(N/A) tmr-GPIO4_DeviceUpdateLoop(GPIO4_DS18B20_Bad_oben) tmr-GPIO4_DeviceUpdateLoop(GPIO4_DS18B20_Drempel_Strasse) tmr-sleep_WakeUpFn(N/A) tmr-sl...
1 - 2020-11-30: s:17:21:26 e:17:21:27 f:1.305 d:tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A)
1 - 2020-11-30: s:17:21:28 e:17:21:29 f:1.669 d:tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-...
1 - 2020-11-30: s:17:21:40 e:17:21:42 f:2.359 d:no bad guy found :-(
1 - 2020-11-30: s:17:21:43 e:17:21:44 f:1.887 d:tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A)
1 - 2020-11-30: s:17:21:55 e:17:21:56 f:1.644 d:tmr-MQTT2_SERVER_keepaliveChecker(MQTT2_FHEM_Server)
1 - 2020-11-30: s:17:22:13 e:17:22:14 f:1.081 d:tmr-GPIO4_DeviceUpdateLoop(GPIO4_DS18B20_Drempel_Strasse)
1 - 2020-11-30: s:17:22:21 e:17:22:22 f:1.476 d:tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-MQTT::Timer(mqtt) tmr-Sa...
1 - 2020-11-30: s:17:22:23 e:17:22:25 f:2.121 d:tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A)
1 - 2020-11-30: s:17:22:30 e:17:22:31 f:1.93 d:tmr-CODE(0x40a70d0)(SIGNALduino_KeepAlive)
1 - 2020-11-30: s:17:22:32 e:17:22:34 f:2.3 d:tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A)
1 - 2021-01-16: s:12:34:03 e:12:34:05 f:2.393 d:no bad guy found :-(

[/edit]
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: Wernieman am 16 Januar 2021, 15:07:55
Da hast Du natürlich auch Recht, anstatt "Warteschlange" kann man den Timer neu setzen....
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 16 Januar 2021, 20:08:36
ZitatWarum nicht vor dem Start des Blocking-Call prüfen, ob andere gerade ausgelesen werden und den Timer neu setzen?
Individuell geht das natürlich. Grundsätzlich im Modul aber nicht. Ich hab ja nicht umsonst einen Sensor, den ich alle 5s abgefragt haben will. ;) Wär blöd, wenn der immer wieder verschoben wird.

ZitatNur FHEM ist manchmal bei 100% CPU (vermutlich während es auch blockiert)
Aber GPIO4 kann es ja nicht sein. Was blockiert denn da ?
ZitatIch habe nun auch mal den Freezemon wieder aktiviert.
Da fällt mir aber doch mehr "tmr-sleep_WakeUpFn(N/A)" ins Auge. Was ist das, dass das so häufig aufgerufen wird ?
Grüße Markus
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: bismosa am 17 Januar 2021, 09:56:00
Hallo!

ZitatIndividuell geht das natürlich. Grundsätzlich im Modul aber nicht. Ich hab ja nicht umsonst einen Sensor, den ich alle 5s abgefragt haben will.
Darf ich fragen, welche Temperatur so zeitkritisch ist, dass sie alle 5s benötigt wird?
Dann darfst Du die letzte Version von dir aber auch nicht verwenden. Hier wird ja immer wieder um die Auslesezeit verschoben (um die Auslesevorgänge zu entzerren)

Ich kann auch meine Version verwenden und einfach glücklich sein. Aber wie wäre es mit einem Attribut? Dann könnte der User entscheiden, ob es zeitkritisch ist.

ZitatAber GPIO4 kann es ja nicht sein. Was blockiert denn da ?
Ich habe jetzt keinen Vergleich angestellt, ob es mit der Version in der CPU-Auslastung besser ist. Das alte Modul hat bestimmt einen Teil dazu beigetragen.

ZitatDa fällt mir aber doch mehr "tmr-sleep_WakeUpFn(N/A)" ins Auge. Was ist das, dass das so häufig aufgerufen wird ?
Ich sehe gerade erst, dass die Zeilen hier abgeschnitten sind. In fast jeder Zeile taucht bei den Freezes auch GPIO4 mit auf. Daher wollte ich mich erstmal darum kümmern  :)

Nachdem ich das nun über Nacht laufen lassen habe, und heute mal in die Log-Datei geschaut habe kommen allerdings wieder viele Freezes.
Nur ein ganz kleiner Auszug:

2021.01.16 20:55:46 1: [Freezemon] myFreezemon: possible freeze starting at 20:55:43, delay is 3.303 possibly caused by: tmr-GPIO4_DeviceUpdateLoop(GPIO4_DS18B20_Dachboden)
2021.01.16 20:55:52 1: [Freezemon] myFreezemon: possible freeze starting at 20:55:47, delay is 5.784 possibly caused by: tmr-at_Exec(at_HeizungGPIO_Test) tmr-sleep_WakeUpFn(N/A) tmr-GPIO4_DeviceUpdateLoop(GPIO4_DS18B20_Drempel_Bad) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-DOIF_SleepTrigger(di_Fenster_Flur)
2021.01.16 21:00:34 1: [Freezemon] myFreezemon: possible freeze starting at 21:00:31, delay is 3.121 possibly caused by: tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-GPIO4_DeviceUpdateLoop(GPIO4_DS18B20_Spielzimmer)
2021.01.16 21:00:39 1: [Freezemon] myFreezemon: possible freeze starting at 21:00:35, delay is 4.129 possibly caused by: tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-sleep_WakeUpFn(N/A) tmr-GPIO4_DeviceUpdateLoop(GPIO4_DS18B20_Netzteil) tmr-MQTT2_SERVER_keepaliveChecker(MQTT2_FHEM_Server) tmr-DOIF_SleepTrigger(di_Fenster_Flur)
2021.01.16 21:43:52 1: [Freezemon] myFreezemon: possible freeze starting at 21:43:51, delay is 1.141 possibly caused by: tmr-GPIO4_DeviceUpdateLoop(GPIO4_DS18B20_Drempel_Strasse)
2021.01.16 22:23:12 1: [Freezemon] myFreezemon: possible freeze starting at 22:23:09, delay is 2.999 possibly caused by: no bad guy found :-(

Sehr häufig taucht auch das squeezebox-Modul auf. Hier lässt sich bestimmt auch noch was machen. (Es liegt nicht nur an GPIO4!)
Auch habe ich gerade irgendwo gefunden, dass man nach Möglochkeit den DNS-Server setzen sollte, um einige blockings zu uumgehen. Das habe ich auch erst eben gerade gemacht.
GPIO4 dürfte ja jetzt eigentlich nicht mehr blockieren...taucht aber immer noch sehr häufig auf...??
Ich werde hier noch weiter suchen müssen. Ich kann aber jetzt schon sagen, das FHEM viel flüssiger läuft als vorher. Ich Pinge mit meinem Display (Kindle) FHEM Regelmäßig an...bisher konnte ich keine Aussetzer feststellen. Auch das Web-Interface läuft nun viel flüssiger  :)

Gruß
Bismosa
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 17 Januar 2021, 11:46:02
ZitatDarf ich fragen, welche Temperatur so zeitkritisch ist, dass sie alle 5s benötigt wird?
Fußbodenheizungsmischer.
ZitatDann darfst Du die letzte Version von dir aber auch nicht verwenden. Hier wird ja immer wieder um die Auslesezeit verschoben (um die Auslesevorgänge zu entzerren)
die war auch nur für Dich zur Analyse.
ZitatIch sehe gerade erst, dass die Zeilen hier abgeschnitten sind. In fast jeder Zeile taucht bei den Freezes auch GPIO4 mit auf. Daher wollte ich mich erstmal darum kümmern  :)
freezemon darf man nicht überinterpretieren. Mit meiner nonblocking-version kann GPIO4 nicht der Schuldige sein. 8) Ich tippe weiter auf  "tmr-sleep_WakeUpFn(N/A)" Sieht seeeehr verdächtig aus.
ZitatAuch habe ich gerade irgendwo gefunden, dass man nach Möglochkeit den DNS-Server setzen sollte, um einige blockings zu uumgehen.
Auf jeden Fall. Dadurch werden Netzzugriffe non-blocking.
Grüße Markus
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: Wernieman am 17 Januar 2021, 11:54:23
ZitatIch Pinge mit meinem Display (Kindle) FHEM Regelmäßig an..
Wie "pingst" du?
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: bismosa am 17 Januar 2021, 13:04:28
Hallo!

ZitatWie "pingst" du?
Ich pinge nicht wirklich. Ich hole per wget eine png...wenn dies nicht erfolgreich ist (also FHEM nicht erreichbar oder png noch nicht fertig) zeige ich eine vorgefertigte error-png.
Also vereinfacht:
URI="http://server:8083/fhem/www/images/status.png"
if wget -q $URI -O $TMPFILE; then
...
else
-> Show error

Ich wollte es hier nicht komplizierter umschreiben als nötig.

Zitatfreezemon darf man nicht überinterpretieren. Mit meiner nonblocking-version kann GPIO4 nicht der Schuldige sein. 8) Ich tippe weiter auf  "tmr-sleep_WakeUpFn(N/A)" Sieht seeeehr verdächtig aus.
Das ist mir klar, das man das nicht überinterpretieren sollte.
Ich lasse jetzt auch mal vollständig dabei loggen. Die "tmr-sleep_WakeUpFn(N/A)" sind kurze Timer, die ich z.B. in den MyUtils setze (FHEM sleeps). Da ist dann auch nichts kritisches dabei.

Ich denke das ist schon alles gut, wie das nun läuft. Den erkannten Hauptverursacher haben wir ja nun (Dank Deiner Hilfe!) gefunden. Alles andere sind dann andere Verursacher.

Gruß
Bismosa
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 07 März 2021, 10:53:59
Hi,
irgendwann, vmtl. Ende Jan., Anf. Feb, wurde etwas in Raspbian(buster) bzgl. 1W verändert. Dadurch werden negative Temperaturen nicht mehr richtig erfasst  (https://forum.fhem.de/index.php/topic,118747.msg1131811.html#msg1131811)
Attached eine entsprechend korrigierte Version für DS18xxx-Sensoren. Die Korrektur hat keine negativen Auswirkungen, wenn man noch eine Altversion des OS hat. Kann also von jedermann bedenkenlos genutzt werden.

Grüße Markus

Edit: Alte Modulversion entfernt. Link zur aktuellsten Version hier (https://forum.fhem.de/index.php/topic,121893.0.html).
Titel: Antw:1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul
Beitrag von: KölnSolar am 02 Juli 2021, 14:25:39
Schließlich auch hier noch der Hinweis, dass es nun einen neuen Thread (https://forum.fhem.de/index.php/topic,121893.0.html) für das Modul gibt, nachdem ich es um die Funktionalität für DHT11/DHT22-Sensoren erweitert habe.

Grüße Markus