DS18b20 mit ESP32 wird durch Wifi gestört

Wiki_:
...
Liegt die Störung an dem Aufbau auf dem breadboard oder ist etwas grundsätzliches dazu bekannt?
...

Ich sehe in deinem Hackstück-Code kein Timing.

Wie oft pro Sekunde rufst du die Werte der DS ab?

Code sollte generell "nicht blockierend" geschrieben werden.

Hallo,
wenn Du davon (DS18B20) 4 Stück auslesen möchtest, dann brauchen die ihre Zeit.
Mindestens 3Sek gesammt für alle. Die Biester sind zeit-kritisch.
Gruß und Spaß
Andreas

SkobyMobil:
Hallo,
wenn Du davon (DS18B20) 4 Stück auslesen möchtest, dann brauchen die ihre Zeit.
Mindestens 3Sek gesammt für alle. Die Biester sind zeit-kritisch.
Gruß und Spaß
Andreas

Aber auch nur im parasitären Modus.
Ob der ESP einen 1k bis 2k PullUp verträgt ist weiß ich nicht...

Wenn die DS als drei Pin angeschlossen sind, ist die benötigte AD-Wandel-Dauer unabhängig von der Anzahl der Sensoren.

Hallo,
mal so...
Gruß und Spaß
Andreas

SkobyMobil:

Der Sensor braucht min 750ms.
Egal wieviele das sind, das braucht jeder einzelne. Somit steht an allen Sensoren nach 750ms ein neuer Wert bereit.

Unabhängig von der Anzahl.

Hi

Bei parasitärer Versorgung musst Du diese Zeit warten, bei normaler Versorgung kannst Du zwischendrin abfragen, ob der DS noch mit Umwandeln beschäftigt ist.
Wenn Du zu früh die Sensorwerte abholst, wird beim parasitär betriebenem DS die Messung unterbrochen (die Versorgung wird ja weg genommen), beim normal versorgtem DS wirst Du einen alten Messwert bekommen.

Oder eben:

  1. Messung auslösen
  2. irgend was sinnvolles tun während der Wartezeit
  3. nach der angegebenen maximalen Umwandlungszeit (750ms bei 12bit) die Daten auslesen.

MfG

Edit Ein DU in ein Du geändert, sind doch nur nette Leute hier, da schreit man doch Keinen an :open_mouth:

Moin,

ich danke schonmal für die Anregungen.

Ich muss dazu sagen, ich in auf der Arduino-Schiene recht frisch unterwegs, ist meine erste Begegnung mit C. Meine vorherigen Projekte spielten auf dem Tiny Tiger und auf dem Raspi.

Zum Timing: in der void loop () werden als erstes analog die vier Spannungen in einer Schleife von 0-100 mit zwischengeschaltetem delay von 10ms abgefragt, um einen Mittelwert zu bilden (Versuch, Störungen auszublenden). Anschliessend schiebe ich die analogen Werte durch eine Korrketurtabelle, um das nichtlineare Verhalten des ESP32 auf dem ADC zu korrigieren. D.h., die DS werden frühestens alle zehn Sekunden abgefragt.

Da die Antwort des Aufrufes von "sensors.requestTemperatures();" ca. drei Sekunden für ne Antwort braucht, hab ich mir vorab keine Gedanken um das Timing bei der Abfrage gemacht sondern vorausgestzt, das erledigt die library. Ich werd mal den Code bereinigen und an der Stelle dann neu ansetzen. Denn wie deutlich zu sehen, hab ich erstmal q&d aus den Beispielsketches das rausgeholt, was mir sinnvoll erschien.

Das, was mich allerdings stutzig macht ist die Tatsache, dass mit ähnlich unstrukturierten sketches die Abfrage der Sensoren absolut stabil läuft, eben nur nicht mit Wifi (als Server).

postmaster-ino:

  1. Messung auslösen
  2. irgend was sinnvolles tun während der Wartezeit
  3. nach der angegebenen maximalen Umwandlungszeit (750ms bei 12bit) die Daten auslesen.

Moin,

aso void loop() sieht bei mir jetzt so aus:

void loop()
{
  Volt0=0;
  Volt1=0;
  Volt2=0;
  Volt3=0;
  sensors.requestTemperatures();          // Temperaturen holen
  for (int i = 1; i < 101; i++)           // Etwas sinnvolles tun
  {
    sensorValue0 = analogRead(sensorPin0);
    Volt0 = Volt0 + sensorValue0;
    sensorValue1 = analogRead(sensorPin1);
    Volt1 = Volt1 + sensorValue1;
    sensorValue2 = analogRead(sensorPin2);
    Volt2 = Volt2 + sensorValue2;
    sensorValue3 = analogRead(sensorPin3);
    Volt3 = Volt3 + sensorValue3;
    delay(10);
  }
  Volt0=ADCKorrektur(Volt0/100);          // Nicht-Linearität des ESP32 grob geradeziehen
  Volt1=ADCKorrektur(Volt1/100);
  Volt2=ADCKorrektur(Volt2/100);
  Volt3=ADCKorrektur(Volt3/100);
  for(int i=0;i<numberOfDevices; i++)     // Schleife zum Auslesen der Temperaturen
  {
    if(sensors.getAddress(tempDeviceAddress, i))
    {
      float tempC = sensors.getTempC(tempDeviceAddress);
      temp[i]=tempC;
      delay(30);
    }
  }
  VoltSchreiben(Volt0, Volt1, Volt2, Volt3, temp);
  webif();                                   // Web-Schnittstelle abfragen, ob ein request vorhanden
}

Damit sollte der Sensor bzw die lib genügend Zeit haben....hilft aber nicht.

Immer noch: vor Wifi.begin(); klappt das Auslesen der Temperaturen gnadenlos, nach Wifi.begin(); nur noch sporadisch. Ich hab probeweise den Wifi-Klamauk komplett auskommentiert, dann tuts wie erwartet. Sobald Wifi im Spiel isses Essig.

...ratlos...

[edit]
-s +d
[/edit]

2 Dinge, die mir zum Ausprobieren noch einfallen würden:

  1. Abfrage der Sensordaten sekundenweise, nicht pausenlos.
  2. Normal anschließen, also nicht im Parasitenmodus

Moin,

Danke für die Ideen, nur leider

1.: Abgefragt werden die Dinger so ca. im 10-Sekundentakt, das zwischendurch stattfindende Auslesen der A/D Wandler dauert ca. so lange.

2.: geht leider nicht, nur zwei Drähte pro Sensor vorhanden. Ich hätte ansonsten von vornherein auf die parasitäre Einspeisung verzichtet.

OK, Dank @all für ihre Gedanken. Werd ich scheints so mit leben müssen und im Web Interface noch die Info über das Alter der einzelnen Temperaturdaten mit auswerfen.

Ich hab so langsam das Gefühl, dass der ESP32 nicht so richtig ausgereift ist. Schon die nicht-Liearität der ADC hat mir schwer zu Schaffen gemacht und jetzt dies noch obendrauf...

In Deinem Code ist nichts vom 10-Sekunden-Takt zu sehen.

Gruß Tommy

Moin,

öhm:

 for (int i = 1; i < 101; i++)           // Etwas sinnvolles tun
  {
    sensorValue0 = analogRead(sensorPin0);
    Volt0 = Volt0 + sensorValue0;
    sensorValue1 = analogRead(sensorPin1);
    Volt1 = Volt1 + sensorValue1;
    sensorValue2 = analogRead(sensorPin2);
    Volt2 = Volt2 + sensorValue2;
    sensorValue3 = analogRead(sensorPin3);
    Volt3 = Volt3 + sensorValue3;
    delay(10);
  }

Danke für den Hinweis. Hast recht, 100 Schleifen mit jeweils 10 ms delay sind keine zehn Sekunden, sondern nur eine. Hatte da iwas im Kopf, was nicht stimmt, man sollte schon in der Lage sein, den eigenen Code zu lesen - zumindest was so eine popelige Schleife anbelangt.

In Summe heisst das, wenn pro Sensor 750 ms benötigt werden, dass ich zu schnell unterwegs bin. Hmmmm, werd mal die millis() zu Rate ziehen, um die Abfrage der Sensoren zu takten.

Versuche mal rauszufinden, ob der nichtblockierende Modus auch parasitär funktioniert. Wenn ja, dann Messung anfordern und nach 1 Sekunde Messwerte holen, ansonsten Pech gehabt.

Gruß Tommy

Moin,

@Tommy: was heist "nichtblockierender Modus"? [edit] Schon gefunden (WaitforConversion(), richtig?)[/edit]

q&d hab ich auf die Schnelle das delay in der Schleife auf 50ms gesetzt, damit hab ich eine Zeitverzögerung von 5 Sekunden zwischen Anforderung der Daten und der Abfrage.

Geändert hat sich nix, Werte kommen nur sporadisch, manchmal erst nach mehreren Minuten im Zufallsprinzip. Im seriellen Log sehe ich, für die lib sind die Sensoren entweder überhaupt nicht erreichbar (nix kann gelesen werden), es kommt als Wert -127 zurück oder eben halt sporadisch der korrekte Wert.

Dann hab ich q&d die Wifi-Funktion auskommentiert (die ich aber benötige). Es kommen sauber und stabil alle fünf Sekunden die Temperaturdaten von allen vier Sensoren an. D.h., es ist genügend Zeit für die Antwort der Sensoren vorhanden, am Timing lieegts also eher nicht.

In Summe sieht es für mich also so aus, dass die Kommunikation mit den parasitär mit 3,3V gespeisten Sensoren bei laufendem Wifi empfindlich gestört wird. Da die I/O Pins des ESP32 nicht 5V-tolerant sein sollen und ich keine Möglichkeit zur separaten Spannungsversorgung der Sensoren hab, muss ich wohl ersteinmal damit leben.

Wie ich schon schrub: Schade, trotzdem Dank @all für die Hilfestellungen.

Auf jeden Fall hab ich schonmal gelernt, dass 100x10=1.000 ist und !=10.000 :-*

Hab gerade das nochmal mit einem nodemcu mit wifi on durchgetestet.
Bei parasiärer Versorgung über D6 und 1k Pullup geht es mit nur einem Sensor. Bei 2en kommt 127.94 bei beiden als Messung

Kann es sein, dass Du Deinen Sketch auf analogRead() geändert hast? Das wird für den DS1820 nix.

Gruß Tommy

Weitere Erkenntnisse:
2 x ds18b20, parasitär an D6 nodemcu, 1k pullup, gehen nicht. Erhöhe ich jedoch die Spannung für den Pullup (NICHT für den nodemcu) von 3,3V auf 3,9V, geht es wie es soll.
dto. mit 1.5k Pullup geht nicht mehr, da brauchts dann min. 4,4V am Pullup

mit 600 Ohm geht es bei 3,3V, bei 3,25V schon nicht mehr

Tommy56:
Kann es sein, dass Du Deinen Sketch auf analogRead() geändert hast? Das wird für den DS1820 nix.

Gruß Tommy

Moin,

nö, für die DS18B20 wäre das mal ein echt sportlicher Ansatz, haste Recht. analogRead() sind die Spannungsmessungen. In der i 1 to 100 werden die Messwerte von den vier ADC summiert, daraus bilde ich danach den Mittelwert. Ansonsten sind die Einstörungen zu groß, so funktionierts recht gut. Mit dem delay(50) hab ich zwischen Messwert anfordern und auslesen eine Verzögerung von 5 Sekunden. Sorry für die Irritation, hier nochmal die komplette void loop():

void loop()
{
  Volt0=0;
  Volt1=0;
  Volt2=0;
  Volt3=0;

  sensors.requestTemperatures();          // Messanforderung

  for (int i = 1; i < 101; i++)           // Etwas sinnvolles tun
  {
    sensorValue0 = analogRead(sensorPin0);
    Volt0 = Volt0 + sensorValue0;
    sensorValue1 = analogRead(sensorPin1);
    Volt1 = Volt1 + sensorValue1;
    sensorValue2 = analogRead(sensorPin2);
    Volt2 = Volt2 + sensorValue2;
    sensorValue3 = analogRead(sensorPin3);
    Volt3 = Volt3 + sensorValue3;
    delay(50);
  }
  Volt0=ADCKorrektur(Volt0/100);          // Nicht-Linearität des ESP32 grob geradeziehen
  Volt1=ADCKorrektur(Volt1/100);
  Volt2=ADCKorrektur(Volt2/100);
  Volt3=ADCKorrektur(Volt3/100);

  for(int i=0;i<numberOfDevices; i++)     // Schleife zum Auslesen der Temperaturen
  {
    if(sensors.getAddress(tempDeviceAddress, i))
    {

      float tempC = sensors.getTempC(tempDeviceAddress);  // Temperaturen holen

      temp[i]=tempC;
      Serial.println(temp[i]);
      delay(30);
    }
  }
  VoltSchreiben(Volt0, Volt1, Volt2, Volt3, temp);
  webif();                                   // Web-Schnittstelle abfragen, ob ein request vorhanden
}

@ElEspanol: Danke für Deine Mühe, ist wohl zwar mit dem ESP8266, gibt mir aber noch ne Idee für mein ESP32 DevBoard.

Ich hab als pullup 4,7k an 3,3V, streng nach Dokumentation. Werde heute abend mal mit kleinerem Widerstand versuchen, wirklich gute Idee.

Ich werd berichten...

Moin,

aso mehrere Pullup-Widerstände bis runter auf 470ohm probiert, das Thema bleibt.

Nach jedem Tausch des Widerstandes immer quergecheckt mit ausgeschaltetem WLAN, dann funktionieren die Dallas - immer, stabil und akkurat.

Fazit: der ESP32 ist nen blödes Teil. Gibt mir zwar ne große Anzahl an ADC (die ich nunmal brauche), Wifi (das ich numal brauche), viel Speicher (den ich zukünftig brauchen werde), geniale Energiesparfunktionen (die ich zukünftig brauchen werde), Bluetooth (ist bei mir auf der Wunschliste), aber die völlig daneben liegenden nicht-linearen Werte der ADC-Ports sowie das jetzige Theater mit dem oneWire und Wifi veranlasst mich zu folgender Aussage:

Sobald Ihr etwas komplexes verwirklichen wollt, lasst die Finger vom ESP32. Als Webserver genial, da viel Speicher und mittlerweile SPIFFS, aber ansonsten für IoT völlig unbrauchbar - auf unterstem Entwicklungsstand auf den Markt geworfener Schrott.

Da ich bei meiner Batterieüberwachung keine Realtime-Werte benötige und bei der Spannungsmessung nix unheimlich genaues bei rumkommen muss, werd ich damit leben und ein Workaround für die Webinfo schaffen, indem ich das Alter der Daten mit anzeige.

Es sei denn, es meldet sich jemand, der mit dem ESP32 oneWire zusammen mit Wifi ans Laufen bekommen hat.

Dank Euch allen für die Infos und Ideen, ich geb an dieser Stelle jetzt auf. Schliesslich ist die Überwachung von vier in Serie geschalteten Bleiakkus keine schwarze Magie und letzendlich nicht so unheimlich zeitkritisch.

Gruß Wiki

Schon die beliebten Keramikkondensatoren großzügig z.B. bei den DS18B20 verbaut (sofern möglich)

Wie soll das denn gehen?
Damit tötest du jegliche Kommunikation mit den Dingern.