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

Begonnen von chunter1, 10 Juni 2017, 13:07:48

Vorheriges Thema - Nächstes Thema

networker

#630
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.


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

Zitat von: HCS am 21 Oktober 2017, 16:12:07
- 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
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

chunter1

Zitat von: networker am 22 Oktober 2017, 11:40:14
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

Zitat von: networker am 22 Oktober 2017, 11:40:14
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:
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:
Zitat0x400878f4:  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?
void OTAUpdate::Handle() {
  ////ArduinoOTA.handle();
}



Zitat von: chunter1 am 22 Oktober 2017, 11:07:48
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

#634
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.

Zitat von: HCS am 22 Oktober 2017, 19:56:59

Kannst Du mal in OtaUpdate.cpp den handle stillegen und verifizieren, dass es dann weg ist?
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.

Zitat von: networker am 22 Oktober 2017, 20:08:20
Kann bestätigen das er mit der Änderung sauber hochfährt
OK, das wird dann wohl ein issue im esp32 core GIT

Zitat von: networker am 22 Oktober 2017, 20:08:20aber 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  :o

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

networker

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

chunter1

Zitat von: networker am 22 Oktober 2017, 22:48:59
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

Zitat von: networker am 24 Oktober 2017, 10:53:01
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

#640
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

Zitat von: HCS am 21 Oktober 2017, 16:12:07
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  :o

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

chunter1

Zitat von: PeMue am 24 Oktober 2017, 21:57:58
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  :o

Einfach 1nF C0G Typen verwenden.  ;)

chunter1

#643
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

Zitat von: chunter1 am 24 Oktober 2017, 22:08:53
Einfach 1nF C0G Typen verwenden.  ;)
Stimmt, da war was  :o Man sollte sich einfach für manche Dinge die Zeit nehmen, die sie brauchen  ;)

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser