Radar basierter WiFi-Niederschlagssensor für Regen, Hagel und Schnee

[networker]

Mein ESP32 hat Probleme beim Reboot und beim Übertragen der Werte an den FHEM

Beim Initialisieren braucht er so ca.3-4 Anläufe (ohne zusätzlichen Eingriff meinerseits) um über Setup done zu kommen und danach einen Connect vom FHEM zu erkennen.

Code: [Auswählen]

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0010,len:4
load:0x3fff0014,len:572
load:0x40078000,len:0
load:0x40078000,len:9880
entry 0x400789d8

Chip ID: B4C92A4AE30
Chip Revision: 0 (2016.09)
Ref:
3 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 4
Start WIFI_STA
HostName is: RainSensor
Using static IP
IP: 10.0.0.183
Mask: 255.255.255.0
Gateway: 10.0.0.138
Hostname: RainSensor
Connect 15 seconds to an AP (SSID 1)
..
connected :-)
SSID: TK_RT_H
IP: 10.0.0.183
Starting frontend
Starting OTA
Starting data port
E (3156) esp_pthread: pthread_getspecific: not supported!
E (3157) esp_pthread: pthread_setspecific: not supported!
abort() was called at PC 0x400deee3 on core 1

Backtrace: 0x400878f4:0x3ffdc4d0 0x400879f3:0x3ffdc4f0 0x400deee3:0x3ffdc510 0x400def2a:0x3ffdc530 0x400df62e:0x3ffdc550 0x400df6b7:0x3ffdc570 0x400deb3a:0x3ffdc590 0x400deaf1:0x3ffdc5b0 0x400dab08:0x3ffdc5d0 0x400db6f2:0x3ffdc610 0x400d4c0e:0x3ffdc630 0x400d9899:0x3ffdc650 0x4012d33f:0x3ffdc750

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0010,len:4
load:0x3fff0014,len:572
load:0x40078000,len:0
load:0x40078000,len:9880
entry 0x400789d8

Chip ID: B4C92A4AE30
Chip Revision: 0 (2016.09)
Ref:
3 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 4
Start WIFI_STA
HostName is: RainSensor
Using static IP
IP: 10.0.0.183
Mask: 255.255.255.0
Gateway: 10.0.0.138
Hostname: RainSensor
Connect 15 seconds to an AP (SSID 1)
..
connected :-)
SSID: TK_RT_H
IP: 10.0.0.183
Starting frontend
Starting OTA
Starting data port
E (6583) esp_pthread: pthread_getspecific: not supported!
E (6583) esp_pthread: pthread_setspecific: not supported!
abort() was called at PC 0x400deee3 on core 1

Backtrace: 0x400878f4:0x3ffdc4d0 0x400879f3:0x3ffdc4f0 0x400deee3:0x3ffdc510 0x400def2a:0x3ffdc530 0x400df62e:0x3ffdc550 0x400df6b7:0x3ffdc570 0x400deb3a:0x3ffdc590 0x400deaf1:0x3ffdc5b0 0x400dab08:0x3ffdc5d0 0x400db6f2:0x3ffdc610 0x400d4c0e:0x3ffdc630 0x400d9899:0x3ffdc650 0x4012d33f:0x3ffdc750

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0010,len:4
load:0x3fff0014,len:572
load:0x40078000,len:0
load:0x40078000,len:9880
entry 0x400789d8

Chip ID: B4C92A4AE30
Chip Revision: 0 (2016.09)
Ref:
3 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 4
Start WIFI_STA
HostName is: RainSensor
Using static IP
IP: 10.0.0.183
Mask: 255.255.255.0
Gateway: 10.0.0.138
Hostname: RainSensor
Connect 15 seconds to an AP (SSID 1)
..
connected :-)
SSID: TK_RT_H
IP: 10.0.0.183
Starting frontend
Starting OTA
Starting data port
Setup done
Port 81: Client connected

Danach läuft der ESP32 stabil, aber manchmal kann man erkennen das nicht alle Readings im Minutentakt aktualisiert werden. Ich habe abstände bis zu 3 Minuten beim Aktualisierungstimestamp gesehen. (state war dabei immer aktuell)

Tritt das bei euch auch auf, oder hat meiner eine Macke?

Edit: Nach dem Ändern der Setup-Werte und anschließenden Speichern ist es genau das gleiche wie beim Einschalten.

[PeMue]

- R5/C8-Beschriftung ist etwas verwirrend, habe gerade noch die Kurve bekommen, wo R5 wirklich hin muss.
- Die Polung der Tantals einzeichnen, dann muss man nicht so viel durchklingeln
- Bei IC1 Pin1 einzeichnen

Ich habe hier mal einen korrigierten Bestückungsdruck mit eingestellt (wie immer im ersten Post auf S. 35  ).

Gruß PeMue

[chunter1]

Mein ESP32 hat Probleme beim Reboot und beim Übertragen der Werte an den FHEM
Beim Initialisieren braucht er so ca.3-4 Anläufe (ohne zusätzlichen Eingriff meinerseits) um über Setup done zu kommen und danach einen Connect vom FHEM zu erkennen.

Ist bei mir auch so.

[HCS]

Tritt das bei euch auch auf, oder hat meiner eine Macke?

Kann es auch reproduzieren. Mit dem Core Rev. 643 selten, mit dem aktuellen häufiger.

Gleiche Exception:

Code: [Auswählen]

Starting frontend
Starting OTA
Starting data port
Setup done
E (7421) esp_pthread: pthread_getspecific: not supported!
E (7421) esp_pthread: pthread_setspecific: not supported!
abort() was called at PC 0x400deee3 on core 1

Backtrace: 0x400878f4:0x3ffdc6d0 0x400879f3:0x3ffdc6f0 0x400deee3:0x3ffdc710 0x400def2a:0x3ffdc730 0x400df62e:0x3ffdc750 0x400df6b7:0x3ffdc770 0x400deb3a:0x3ffdc790 0x400deaf1:0x3ffdc7b0 0x400daca4:0x3ffdc7d0 0x400dbaea:0x3ffdc810 0x400d597a:0x3ffdc830 0x400d2c98:0x3ffdc850 0x4012d358:0x3ffdc870

Ich habe mal den backtrace rausgelesen:

0x400878f4:  invoke_abort panic.c:553 
0x400879f3:  abort panic.c:553 
0x400deee3:  __cxxabiv1::__terminate(void (*)()) eh_terminate.cc:112 
0x400def2a:  std::terminate() eh_terminate.cc:112 
0x400df62e:  __cxa_get_globals eh_globals.cc:133 
0x400df6b7:  __cxa_throw eh_throw.cc:65 
0x400deb3a:  operator new(unsigned int) new_op.cc:54 
0x400deaf1:  operator new[](unsigned int) new_opv.cc:32 
0x400daca4:  WiFiUDP::parsePacket() WiFiUdp.cpp:129 
0x400dbaea:  ArduinoOTAClass::handle() ArduinoOTA.cpp:355 
0x400d597a:  OTAUpdate::Handle() OTAUpdate.cpp:80 
0x400d2c98:  loop() precipitationSensorESP32.cpp:330 
0x4012d358:  loopTask(void*) main.cpp:18 (discriminator 1) 

Das kommt aus ArduinoOTAClass wenn der handle() aufgerufen wird.

Kannst Du mal in OtaUpdate.cpp den handle stillegen und verifizieren, dass es dann weg ist?

Code: [Auswählen]

void OTAUpdate::Handle() {
  ////ArduinoOTA.handle();
}

Die 0.15.1 wirkt sich nur auf die ...korr Werte aus.

Stimmt. Das ist der Unterschied zwischen RSSI=-40 und RSSI=-75
Habe den Lautsprecher dran gemacht. Bei der Position weiter weg höre ich das WiFi deutlich, in zwei Meter Abstand zum AP ist Ruhe.

[networker]

Kann bestätigen das er mit der Änderung sauber hochfährt, aber an der Datenübermittlung hab ich noch immer lags von bis zu 5 Min, wobei "state" alle Minuten aktualisiert wird.

Kannst Du mal in OtaUpdate.cpp den handle stillegen und verifizieren, dass es dann weg ist?

Code: [Auswählen]

void OTAUpdate::Handle() {
  ////ArduinoOTA.handle();
}

[HCS]

Ich habe gerade 36_PrecipitationSensor.pm aus dem GIT genommen und offiziell in FHEM eingecheckt.
Das FHEM-Update liefert es dann ab morgen mit aus.

Kann bestätigen das er mit der Änderung sauber hochfährt

OK, das wird dann wohl ein issue im esp32 core GIT

aber an der Datenübermittlung hab ich noch immer lags von bis zu 5 Min, wobei "state" alle Minuten aktualisiert wird.

Das konnte ich nicht beobachten.
Ich kann aber erst mal eh nichts mehr beobachten. Mir ist gerade ohne erkennbaren Grund der Regler auf dem Himalaya-Board abgeraucht 

Aber letzte Nacht in den Logs waren keine Lücken, zumindest keine, die ich entdeckt hätte.

[networker]

Habe einmal im Plot von Step auf Point umgestellt, damit wird das ganze auch im Plot sichtbar.

[chunter1]

Habe einmal im Plot von Step auf Point umgestellt, damit wird das ganze auch im Plot sichtbar.

Meine beiden Setups zeigen keine Aussetzer.
Ist die WLAN Signalstärke bei dir ok?

[networker]

Habe einen RSSI von -45, abgelesen von der Home-Seite am ESP32

ESP32 steht/liegt 3m neben dem Accesspoint ohne irgendwas dazwischen.

FHEM1 hängt am Ethernet mittels Kabel, FHEM2 hängt im WLAN, und beide haben zum gleichen Zeitpunkt die Aussetzer.

[HCS]

FHEM1 hängt am Ethernet mittels Kabel, FHEM2 hängt im WLAN, und beide haben zum gleichen Zeitpunkt die Aussetzer.

Oh, Du hast zwei FHEMs auf einem Radar sitzen?
Nimm mal eins weg, ob die Probleme dann verschwinden.
Die Strategie "ein DataPort für mehrere FHEMs" anstatt "mehrer DatPorts 81,82,83 für mehrere FHEMs" ist brandneu.
Eventuell produziert das ja die Aussetzer.

[networker]

Nur um das nicht falsch zu verstehen, ein FHEM ist Produktiv, der 2. die Spielwiese.

Um zu Verifizieren ob beide das gleiche sehen, habe ich am Produktivsystem auch den Sensor provisioniert und anschließend wieder auf disabled =1 gesetzt.

Werde diese Woche einmal versuchen den Verkehr ESP32 <--> FHEM im WLAN zu Sniffern.

[PeMue]

Ich habe eine PeMue-Platine bestückt und in Betrieb genommen.

So wie das aussieht, hast Du für die 0805 Kondensatoren Keramiktypen genommen, korrekt? Ich habe mal (auch für die Kollegen, die das Hühnerfutter wollten) Folientypen bestellt, aber die sind kosten halt satt das 10-fache  Also nix mit Cent-Beträgen 

Gruß PeMue

[chunter1]

So wie das aussieht, hast Du für die 0805 Kondensatoren Keramiktypen genommen, korrekt? Ich habe mal (auch für die Kollegen, die das Hühnerfutter wollten) Folientypen bestellt, aber die sind kosten halt satt das 10-fache  Also nix mit Cent-Beträgen 

Einfach 1nF C0G Typen verwenden. 

[chunter1]

Hat übrigens jemand von den Platinenbesitzern die Möglichkeit exakte Niederschlagsmengen-Messungen durchzuführen?
Ich besitze nur eine 0815 Wetterstation und weiß nicht in wie weit ich die Messwerte als Referenz ernst nehmen soll. 

Anbei der aktuelle Versuch passende Koeffizienten für maximale Korrelation der Niederschlagswerte zu errechnen.

grüne Linie = Wetterstation Ventus
rote Linie = Radar

[PeMue]

Einfach 1nF C0G Typen verwenden. 

Stimmt, da war was  Man sollte sich einfach für manche Dinge die Zeit nehmen, die sie brauchen 

Gruß PeMue