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

#256
ZitatZumindest Vin (+5V) und GND liegen bei beiden Boards an der selben Stelle.
Wie wäre es wenn wir den "Board-Typ/das Pin-mapping" per Software selektierbar machen (zumindest für die beiden obigen ESP32 Dev.-Board Varianten)?
Die drei IOs (32=Watchdog, 33=DS18B20, 34=ADC) flexibel zu gestalten, hält sich vom Aufwand her in Grenzen.

Oder via simpler Lötbrücken die entsprechenden Pins "aktivieren".

Verkabelung zum und vom Bord könnte man bei den wenigen notwendigen Verbindungen auch mittels Kupferlackdraht von Pfostenstecker zu Pfostenstecker herstellen.

Ich glaube aber auch das die Breite einiger Boards unterschiedlich ist.

chunter1

Zitat von: networker am 02 August 2017, 20:53:44
Ich glaube aber auch das die Breite einiger Boards unterschiedlich ist.

Solange bei den in Frage kommenden Varianten der +5V und GND Pin nebeneinander liegen, wäre das eigentlich auch lösbar.
Vielleicht sollte mal jeder, der Interesse an einem PCB hat, seine ESP32 Board-Variante posten und wir schaun ob wir "alle" ohne Aufwand abdecken können.

sbiermann

Zitat von: chunter1 am 02 August 2017, 21:24:03
Solange bei den in Frage kommenden Varianten der +5V und GND Pin nebeneinander liegen, wäre das eigentlich auch lösbar.
Vielleicht sollte mal jeder, der Interesse an einem PCB hat, seine ESP32 Board-Variante posten und wir schaun ob wir "alle" ohne Aufwand abdecken können.
Wie eben schon gepostet, hier meine ESP32 Variante: https://de.aliexpress.com/item/WEMOS-LOLIN32-V1-0-0-wifi-bluetooth-board-based-ESP-32-4MB-FLASH/32808551116.html

chunter1

Zitat von: chunter1 am 02 August 2017, 21:24:03
Solange bei den in Frage kommenden Varianten der +5V und GND Pin nebeneinander liegen, wäre das eigentlich auch lösbar.
Ich sehe grade, dass beim meiner Variante nicht GND sondern CMD neben der 5V Versorgung steht und bei den anderen bisher geposteten boards die Reihenfolge verdreht ist.
Lässt sich wohl doch nur mit Lötbrücken lösen?

chunter1

Zitat von: HCS am 02 August 2017, 09:04:05
Heute um 07:03 ist er wieder stehen geblieben.

Hast du im Setup bei Publish mehrere oder nur die "Compact" Version aktiviert?
Ich hatte die verschiedenen Optionen im Code ursprünglich immer nur einzeln aktiv um die Kommunikation/die Datenmenge immer möglichst gering zuhalten.

HCS

Zitat von: chunter1 am 03 August 2017, 09:41:08
Hast du im Setup bei Publish mehrere oder nur die "Compact" Version aktiviert?
Nur die Compact und publish interval 30 Sekunden.

Heute Nacht ist das Rohr wieder stehen geblieben, aber leider ist es noch draußen.
Ich hole es heute Abend rein und hänge es an einen Rechner um zu sehen, ob es mit einer Exception stirbt oder einfach so stehen bleibt.
Das ist eine mühselige Geschichte, weil es durchaus mal ein bis zwei Tage braucht, bis es steht  :(

Hast Du irgend welche Abstürze mit V0.7 oder höher?

Ich muss mal noch etwas einbauen, das die Chip-Revision anzeigt, also ob es ein Rev 0 (2016.09) oder Rev 1 (2017.02) ist.
Ich glaube alle meine ESP32 sind Rev 0.


Anderes Thema: liest Du die mit?
Weil die betreffen Dein ADC-sampling ja voll.
https://github.com/espressif/arduino-esp32/issues/92
https://github.com/espressif/esp-idf/issues/164

Wobei es sowohl in den esp-idf issues als auch in den arduino-esp32 issues weitere interessante Dinge zum Thema ADC gibt.






SusisStrolch

Zitat von: HCS am 03 August 2017, 12:44:28
Ich hole es heute Abend rein und hänge es an einen Rechner um zu sehen, ob es mit einer Exception stirbt oder einfach so stehen bleibt.
Du hast doch bestimmt noch ne NodeMCU oder WeMos im Fundus...
esp-link drauf und dann via netcat mitloggen...

Zitat von: HCS am 03 August 2017, 12:44:28
Das ist eine mühselige Geschichte, weil es durchaus mal ein bis zwei Tage braucht, bis es steht  :(
Ja ja, das Alter...  8)
Synology DS1515+, 16GB RAM, 4x 6TB WD-Red
- Docker (FHEM), MariaDB, MariaDB10, Surveillance Station
Gateways: LCG miniCUL433, LCG miniCUL868, AVR-X4000, VU-Solo SE, Kodi
ESP8266: ESPEasy (S0-Counter, Temp/Hum), Sonoff TH, Sonoff 4ch

HCS

Zitat von: SusisStrolch am 03 August 2017, 15:01:39
Du hast doch bestimmt noch ne NodeMCU oder WeMos im Fundus...
esp-link drauf und dann via netcat mitloggen...
Auch eine Variante. Aber kurz auf die Terrasse laufen und das Rohr den zylindrischen Radarsensor holen geht schneller.

Zitat von: SusisStrolch am 03 August 2017, 15:01:39
Ja ja, das Alter...  8)
Uff. Das wird mir jetzt erst klar, was ich da geschrieben habe.  :-[
Ich steige auf den Begriff "zylindrischer Radarsensor um"  ;D ;D ;D

@chunter1: ich kann auch nicht ausschließen, dass der WebServer die Crashes verursacht.

Wir werden sehen. Ich habe das Thema auf alle Fälle auf dem Radar.  ;D ;D ;D

chunter1

#264
Zitat von: HCS am 03 August 2017, 12:44:28
Heute Nacht ist das Rohr wieder stehen geblieben, aber leider ist es noch draußen.
Das ist eine mühselige Geschichte, weil es durchaus mal ein bis zwei Tage braucht, bis es steht  :(
Wie lange ist das USB Kabel das du verwendest? (Netzteil -> ESP32)
Schalt mal bewusst das Licht oder sonstige größere Verbraucher in dem Raum oft ein und aus.
Ideal wäre, wenn du den Schalter grade so gedrückt hältst, dass er prellt und die Lampen flackern.
Sollte der ESP32 dann abstürzen, hast du ein klassisches EMV Problem.

Zitat
Hast Du irgend welche Abstürze mit V0.7 oder höher?
Vielleicht einen - hab gestern auf 8192k umgestellt - bisher (23h) kein Problem.
Ich muss aber auch dazu sagen, dass ich das Webinterface extrem selten öffne, um jeglichen Einfluss zu vermeiden.

Zitat
Anderes Thema: liest Du die mit?
Weil die betreffen Dein ADC-sampling ja voll.
Die kenn ich, ja.
Geht aber bei uns sowieso im Rauschen unter.  ;)

Morgen wird der neue Premap getestet und wenn sichs ausgeht, der Sensor in das DN40 übersiedelt.
Der nächste Regentag steht vor der Türe!

HCS

Zitat von: chunter1 am 03 August 2017, 17:10:42
Wie lange ist das USB Kabel das du verwendest? (Netzteil -> ESP32)
ca. 1 Meter

Zitat von: chunter1 am 03 August 2017, 17:10:42
Schalt mal bewusst das Licht oder sonstige größere Verbraucher in dem Raum oft ein und aus.
Ideal wäre, wenn du den Schalter grade so gedrückt hältst, dass er prellt und die Lampen flackern.
Sollte der ESP32 dann abstürzen, hast du ein klassisches EMV Problem.
Da ist nichts außer einer Pumpe und die schaltet Nachts um 1 Uhr keiner ein.
Aber ich werde es ja sehen, wenn ich es wieder im Büro liegen habe, ob es dann immer noch auftritt.

Zitat von: chunter1 am 03 August 2017, 17:10:42
Vielleicht einen - hab gestern auf 8192k umgestellt - bisher (23h) kein Problem.
OK, wenn Du crashes hast, gib bitte Bescheid.

Zitat von: chunter1 am 03 August 2017, 17:10:42
Ich muss aber auch dazu sagen, dass ich das Webinterface extrem selten öffne, um jeglichen Einfluss zu vermeiden.
Ich auch und da war Nachts um 1 Uhr genauso wenig jemand drauf wie am Schalter für die Pumpe.

Ich will EMV nicht ausschließen, aber es steht aktuell auf meiner "warum passiert der Sch..."-Liste recht weit hinten.

Man sieht im Anhang schön: es hat bis 0:46 Uhr vor sich hin gerauscht, und dann war es weg.

Was mir beim experimentieren aufgefallen ist: wenn die konfigurierte FHEM-IP nicht erreichbar ist, dann kommt es aus der publish ewig lang nicht raus, blockiert das WebFrontend so heftig, dass man es kaum schafft, eine andere IP zu konfigurieren und hagelt RB overflows.
Aber die FHEM-Anbindung ist ja eh noch ein offenes Thema.



networker

#266
Ev.  könnten wir die FHEM Kommunikation auf mqtt umlegen.

Soll angeblich mit der 8266 Implementierung von pubSubClient laufen.

https://techtutorialsx.com/2017/04/24/esp32-subscribing-to-mqtt-topic/

chunter1

Zitat von: networker am 03 August 2017, 20:01:03
Ev.  könnten wir die FHEM Kommunikation auf mqtt umlegen.

Soll angeblich mit der 8266 Implementierung von pubSubClient laufen.

https://techtutorialsx.com/2017/04/24/esp32-subscribing-to-mqtt-topic/

Und ich hoffe, es findet sich wer der das KVP beisteuert.

HCS

Zitat von: chunter1 am 03 August 2017, 21:37:47
Und ich hoffe, es findet sich wer der das KVP beisteuert.
Du meinst, um mit 36_KeyValueProtocol.pm zu kommunizieren?
Falls ja, sollte kein Problem sein, habe es ja geschrieben  ;)

Meiner Meinung nach wäre der richtige Weg:
TCP-DataPort im precipitationSensorESP32 ----> FHEM-Modul 36_precipitationSensor.pm
precipitationSensorESP32 misst und liefert die Daten (grob das, was compact jetzt schon liefert) in einer kompakten Form.
36_precipitationSensor.pm hat die "intelligenz", daraus abzuleiten, ob es regnet oder ein Storch vorbeigeflogen ist.

Wenn ich nicht falsch liege, soll doch das Endergebnis (bildlich und etwas vereinfacht gesagt) ein reading sein, das "kein Niederschlag" / "regnet" / "hagelt" / "schneit" sein kann und eventuell noch eine Intensität.

36_precipitationSensor.pm kann dann, wie 36_LaCrosseGateway.pm, die Helferlein wie z.B. OTA-Update usw. bekommen.

Solange sich kein FHEM auf den DataPort verunden hat, muss precipitationSensorESP32 sich keinen Stress machen, um die Daten bei einem Ziel abzuliefern, das es evtl. gerade gar nicht gibt.

Aber die Grenze, wofür der Sketch noch zuständig ist und wo die Zuständigkeit eines FHEM-Moduls beginnt, kann man natürlich hin und her schieben.
Generell ist es aber eher die FHEM-Strategie, dass ein Sensor seine Daten abliefert und es dann in FHEM zu einer Bedeutung verarbeitet wird.

chunter1

#269
Zitat von: HCS am 04 August 2017, 12:45:56
Falls ja, sollte kein Problem sein, habe es ja geschrieben  ;)
ouch! :) vergessen

Anbei mein aktueller Testaufbau.
Wie befürchtet, stört der ESP32 bei aktiver WLAN-Kommunikation den Preamp massiv.
Der geringe Abstand und der Aufbau mit THT Bauteilen auf Lochrasterplatine sind alles andere als optimal.

Was ich testweise ausprobieren möchte ist, das WLAN während der Messung in einen power-down/sleep-mode zu versetzen und nur für die Übertragung zu aktivieren.
Weiß zufällig wer wie das geht?