Die üppige Vegetation hier in Thailand ist der Wärme aber auch den teils heftigen Niederschlägen geschuldet. Die Temperaturen bewegen sich im Bereich von 25-35°C und lassen keinen Sommer oder Winter erkennen. Schön ist das hier zu sehen. Die eigene Temperaturaufzeichnung in Home Assistant bestätigt auch die hohe Luftfeuchtigkeit.

Die Jahresregenmenge kann bis zu 1600 Liter/m2 betragen. In Deutschland ist es je nach Region weniger als die Hälfte.

Allerdings erfassen wir bisher nicht die wirkliche Regenmenge auf unserem Grundstück. Ein Grund genug für ein neues Projekt…

Es gibt eine große Menge an Regensensoren die allerdings nur erkennen ob es gerade regnet. Das kann hilfreich um automatisch zum Beispiel eine Markise ein- oder auszufahren. Wir wollen aber die Regenmenge messen. Daher brauchen wir einen Sensor der die Regenmenge definiert auffängt. Dazu gibt es in Wikipedia gute Informationen.

Ein digitaler Niederschlagsmesser verwendet einen Trichter um das Regenwasser zu bündeln und dann auf eine Kippwaage zu führen. Ist die eine Seite vollgelaufen dann kippt die Waage, entleert die vollgelaufene Hälfte und die zweite Seite kann voll laufen. Zählt man die Anzahl der Kippvorgänge hat man ein gutes Maß für die Regenmenge. Natürlich muss das Maß für den Trichtereinlass sowie die Aufnahmemenge der Kippwaage bekannt sein. Genau solch einen Sensor kann man auch selber bauen. Hier ist ein gutes Beispiel mit 3D Druck. Es gibt diese Art Sensoren aber auch fertig als Zubehörteil für proprietäre Wetterstationen. Ein Anbieter ist TFA Drostmann:

Der Sensor ist batteriebetrieben und sendet die Messwerte auf 433MHz. Er kann also irgendwo draussen im Garten positioniert werden. Um den Sensor für eigene Anwendungen wie Home Assistant verwenden zu können bedarf es Reverse Engineering. Das Trichtergehäuse läßt sich einfach entfernen. Zum Vorschein kommt die Kippwaage mit dem dahinter liegenden Gehäuse für die Elektronik. Ein Magnet in der Kippwaage stimuliert einen Reedkontakt im Innern. Das Batteriefach (2xAA) ist von unten zugänglich.

Im Innern residieren zwei Platinen. Eine mit dem Reedkontakt und COB (Chip On Board) und das zweite PCB ist der Sender (433MHz)

Diese Trennung erlaubt uns einfach das Protokoll zum Sender abzugreifen.

Im Batteriefach gibt es eine Triggertaste, die den aktuellen Messwert sofort sendet. Praktisch für die Aufzeichnung mit einem Logicanalyzer, dann braucht man nicht bis zum nächsten Frame zu warten. Zunächst fällt auf, dass das Protokoll anscheinen 8 mal wiederholt ausgegeben wird mit einer Pause von ca. 9ms dazwischen.

Zoomt man weiter hinein dann zeigt der SALEAE Logic Analzer ein ASK (Amplitude-shift keying) Protokoll. Zwischen einem immer gleich langen Highpuls von ca. 488µs kommen zwei Typen von Pausen, eine 2ms und die andere 4ms lang.

Schauen wir uns num mal an, ob das auch so gesendet wird.

Ein preiswerte Möglichkeit für Untersuchungen im Frequenzbereich so bis ca. 1766 MHz. Das reicht für die 433MHz des Regensensors aus. Als Hardwarebasis dient ein 'alter' DVB-T Stick sofern er den Chipsatz RTL2832U+R820T2 beinhaltet. Der lässt sich nämlich frei programmieren. Ich habe mich für das Set von DollaTek entschieden was für ca. 25,- € im Online-Markt der Wahl zu beschaffen ist.

Die Fernbedienung und auch die Treiber-CD brauchen wir nicht, Antenne und der Stick reichen für die weiteren Untersuchungen aus. Der Stick wird in gängigen PCs automatisch erkannt. Alle weiteren Untersuchungen wurden unter OSX ausgeführt, dürften ähnlich aber auch Windows funktionieren.

Für den Stick brauchen wir nun die richtige Analyse-S/W. Unter SDR software for Windows Linux Mac OS & drivers RTL-SDR gibt es eine übersichtliche Aufstellung. Bei OSX bieten sich da folgende Programme an:

1. GQRX
2. cubicSDR
3. SDRAngel
4. Universal Radio Hacker (URH)

Sie sind alle kostenlos und Open Source. Für meine Untersuchung habe ich URH verwendet, da es alle Analyzeschritte in einem Program vereint. Zuerst schauen wir uns mal das Frequenzspektrum um 433MHz an, ob tatsächlich ein Signal vom Regensensor gesendet wird. Dazu starten wir im URH die Funktion Spectrum Analyzer… und Trigger den Sendeframe durch Drücken der Taste im Batteriefach. Vor dem Start der Messung muss man noch das Device auswählen, in unserem Fall der USB Stick RTL-SDR. Das Ergebnis zeigt tatsächlich bei 433.95MHz ein Sendesignal.

Im blauen Block ist der zeitliche Verlauf aufgezeichnet (x=Frequenz, y=Zeit) und die Farbe gibt die Signalintensität an (je wärmer um so stärker). Darüber ist der Amplitudenverlauf über die Frequenz aufgetragen. Mit der Erkenntnis können wir das Signal nun aufzeichnen und weiter untersuchen. Dazu rufen wir die Funktion Record Signal… auf. Dann wieder das Device auswählen und die Frequenzen passend einstellen:

Das Ergebnis zeigt nun das aufgezeichnete Signal im zeitlichen Verlauf. Wir erkennen die sich achtmal wiederholenden Frameanteile und im Zoom die schon im digitalen Signal vorher beschriebenen Pulse und Pausen. Diese Aufzeichnung speichern wir an einer wiederzufindenen Stelle ab.

Jetzt ist es an der Zeit in URH ein neues Projekt anzulegen damit wir die nächsten Schritte auch abspeichern können. Dann gehen wir auf den Reiter Interpretation und laden das aufgezeichnete Signal. Jetzt können wir dieses Signal 'interpretieren'. Dazu stellen wir die Modulation auf ASK, die Anzahl der Samples/Symbol auf z.B. 500. Unten wurde das Signal jetzt in einen Bitstrom umgewandelt. Jede Highamplitude wird zur 1 und die Pausen dazwischen zu 0 gesetzt:

Auch hier ist wieder die Pulsfolge mit den zwei unterschiedlich langen Pausen zu finden 100000000100000000100001000010000100001…. Um das Signal zu decodieren gehen wir auf den Reiter Analysis und definieren unter Decoding ein neues Decoding format mit dem Namen PDM:

Um den vorgegebenen Decoder Morse Code nutzen zu können, invertieren wir das Signal vorher mit Invert. Dann müssen wir noch die Morsecode Parameter festlegen. Nach der Invertierung haben wir genau eine NULL und dann entweder 4 oder 8 Einsen:

• Maximum () length of 1-sequence for Low (0) = 4
• Minimum () length of 1-sequence for High (1) = 7
• Number of 0s between 1-sequences (just for encoding) = 1

Wenn alles richtig eingestellt ist, wird der Frame ohne Fehler decodiert. Die 8 Frames erscheinen jetzt in der Liste. Jeder <frame besteht aus 36 Bits deren Bedeutung wir nun empirisch herausfinden müssen. Dazu legen wir einen neuen Message Type Rain_Sensor an. Nun können wir die Bits passend gruppieren und der jeweilige Wert wird sofort in der Spalte Value angezeigt. In der Fragilste kann man sehen dass der 6. gesendete Frame korrupter ist und der 8. nicht mehr vollständig gesendet wurde. Da aber die Daten einer Sendesequenz immer alle gleich sind, reicht ein korrekter Frame aus 36 Bytes. Für die Gruppierung findet man im Netz einige typische Beispiele die man als Startvorlage nehmen kann. Das Ergebnis der Dekodieren hier nochmals zusammengefasst:

 0000 0000 0011 1111 1111 2222 2222 2233 3333
 0123 4567 8901 2345 6789 0123 4567 8901 2345
|----|----|----|----|----|----|----|----|----
 aaaa aaaa RRbs tttt tttt tttt rrrr rrrr CCCC
 LSB - MSB      LSB ------ MSB LSB - MSB

 a:  8 bit address id (random after battery change)
 b:  1 bit battery state 0 == OK
 s:  1 bit force TX switch 1 == switch pressed
 R:  2 bit MSB of rain value
 t: 12 bit signed temperature * 10 (eg: 23,1 send as 231)
 r:  8 bit LSB of rain value
 C:  4 bit checksum of 8 nibbles send

• https://www.home-assistant.io Home Assistant
• https://esphome.io ESPHome
• https://airbnb.com/h/villarollokohsamui Man kann bei uns Urlaub verbringen…

Wenn ihr meine Arbeit unterstützen wollt, so könnt ihr mir gerne einen Cappuccino oder so spenden: .