1wire auf Raspberry direkt auf GPIO4 mit w1-gpio-Modul

[bismosa]

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:

Code Auswählen Erweitern


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

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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

[KölnSolar]

Irgendwie funktioniert es leider doch nicht so richtig bei mir 

dachte ich es mir doch. Das

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.

war nicht logisch nachvollziehbar.

Zeile 211 sieht in meiner Version so aus

Code Auswählen Erweitern

if (<DATA> =~ /YES/) { und die Zeile davor

Code Auswählen Erweitern

return $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 ?

Ich 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

Code Auswählen Erweitern

if (<DATA> && <DATA> =~ /YES/) {(ungetestet)
Grüße Markus

[bismosa]

Hallo!

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

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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern



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!

Kansst 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

[KölnSolar]

Also ist doch nichts in <DATA> vorhanden?

Naja, Du fängst jetzt nicht mehr das fehlgeschlagene open ab.(warum auch immer es fehlschlägt. Rpi4 ?)
den

Code Auswählen Erweitern

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 YESfinde 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  )

bitte 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

[bismosa]

Hallo!

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

[bismosa]

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

[KölnSolar]

was sagt dmesg ? immer wieder disconnects oder ist der bus stabil ?
parasitär oder separate Spannungsversorgung ?
Grüße Markus

[bismosa]

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

Code Auswählen Erweitern


#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

[KölnSolar]

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.

Interessant

Da 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

[bismosa]

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

[Wernieman]

Ethernet oder WLAN?

So etwas habe ich bei Ethernet (LAN) beim Pi noch nie gehabt ....

[KölnSolar]

Witzigerweise 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

[bismosa]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern

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

[KölnSolar]

Hi,

Vielleicht 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

[bismosa]

Hallo!

Und 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 

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 ?

Pollingmode ist nichts eingestellt. Auch kein Intervall. Also sollte der Standardintervall verwendet werden.

Kannst 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