Bodenfeuchte Sensor für Gartenbewässerung

[rdeckard]

Im ehemaligen Sammelbestellung Nachbars-Thread wurde auch über den Truebner SMT50 und SMT100 Sensor diskutiert. Da dieser Thread vom Thema eigentlich abgeschlossen ist und sowieso in einem eher verwaisten Bereich liegt, erlaube ich es mir, hier fortzufahren.

Das Thema max. Kabellänge beim SMT50 hat mich etwas zur (wesentlich teureren) SMT100 Version hingezogen, wobei mir da durchaus die digitale RS485-Variante gefällt. Heute erhielt ich vom Hersteller noch ein paar Infos, die vielleicht den einen oder anderen hier interessieren können (ich habe auch noch wegen dem RS485 TrueHub angefragt):

Die Kabel dürfen beim SMT50 auch länger sein als 25 Meter, wenn die Betriebsspannung nicht gerade an der untersten Grenze von 3,3 Volt liegt (dies ist die minimale Angabe laut unserem Datenblatt). Sofern Sie den SMT50 mit einer höheren Spannung (z.B. 5V) versorgen, kann das Kabel problemlos länger sein bis zu etwa 100m. Bitte beachten Sie, dass lange Kabel bei analogen Signalen auch oft zu einem erhöhten Rauschen führen. Dies kann aber sehr gut durch Mittelwertbildung beim Messen eliminiert werden.

Der SMT100 ist einer der derzeit genausten und besten Bodenfeuchtesensoren, den es am Markt gibt. Verglichen mit dem SMT50 natürlich bedingt durch die aufwendige Technik deutlich teurer, allerdings verglichen zu den anderen Sensoren dieser Leistungsklasse am Markt sehr günstig.

Hauptunterschied zum SMT50 ist die Frequenz des verwendeten Messsignals. Aus physikalischen Gründen wird die Bodenfeuchtemessung bei sehr hohen Signalfrequenzen genauer, da sie weniger beeinflusst wird z.B. von der Leitfähigkeit des Bodens (Dünger etc...). Der SMT100 arbeitet hier mit extrem hohen Signalfrequenzen von bis zu 300 MHz und ist daher sehr genau. Für reine Bewässerungszwecke im Hausgarten ist das aber in der Regel nicht erforderlich.

Sofern Sie sich dennoch für den hochwertigeren SMT100 entscheiden, können Sie mit dem RS-485-Anschluss ein Bussystem aufbauen, also alle Sensoren direkt miteinander verbinden. Dazu benötigen Sie kein weiteres Zubehör wie den TrueHub100. Sie müssen in diesem Fall jedem Sensor eine eigene Adresse zuweisen (vor der Verkabelung), anschließend können Sie dann über geeignete Befehle jeden einzelnen Sensor am Bus über seine individuelle Adresse ansprechen. Die Implementierung eines solchen Systems erfordert in der Regel jedoch etwas Erfahrung mit Schnittstellen und der Programmierung der Kommunikation. Beispiele mit dem einfachen ASCII-Protokoll können Sie hier ansehen:

http://www.truebner.de/sites/default/files/AN005.pdf

Mit welcher Spannung haben den die bisherigen SMT50 Besitzer ihre Sensoren versorgt? (Weil hier ja bei Längen von >25m Probleme aufgetreten waren. Oder lag das mehr am KNX-Analog Eingang??)

Aktuell kämen bei mir die beiden folgenden Varianten in Frage (bei ca. 5-6 Sensoren):

Vernunftslösung
SMT50 Sensoren mit Sternverkabelung in am Haus angrenzenden Anbau, welcher mit Strom, LAN und KNX versorgt ist. Dort würden dann 2 MDT KNX-Analog Geräte montiert, sowie natürlich ein mindestens 5V Netzgerät für die Sensoren.
Abfrage der Werte erfolgt dann über den KNX-Bus mit Edomi Logiken (für die Bewässerung). Optional in Edomi noch ein Diagramm (Datenlogger).
Wegen dem Rauschen müsste man die Werte etwas mitteln, was eher einem "Ungefähr"-Wert als wirklich einer präzisen Messung entspricht. (Sollte aber für die Zwecke reichen.)

Luxuslösung
SMT100 RS485 ASCII Sensoren mit Busverkabelung in am Haus angrenzenden Anbau. Dort würde ich ein Arduino/Rasperry Pi mit RS485 Shield installieren, welches die Messwerte aufzeichnet und z.B. per integrierten Webserver im internen Netz zur Verfügung stellt.
Abfrage der Werte erfolgt dann über den Webserver mit Edomi Logiken. Hier wäre zwar etwas Programmieraufwand bezüglich Arduino/Rasperry Pi nötig, dafür muss man nicht mitteln und kann die Werte exakt abrufen (mit einer zudem viel höheren Auflösung).

Die Luxuslösung ist zwar von den Sensoren wesentlich teurer, dafür spare ich mir bisschen bei den KNX-Analog-Geräten. Die Luxuslösung verspricht natürlich auch viel bessere Werte (wenn jemand z.B. die genaue Bodentemperatur interessiert).

[gkamp]

Hallo zusammen, hallo @rdeckard,

ich stehe aktuell auch vor dem Beginn der Gartenbewässerung bzw. Bodenfeuchtemessungs-Planung.

Wie sind Eure Erfahrungen mit dem SMT50 bzw. SMT100? Ich würde die Sensoren (evtl. 4 Stück, je einen pro Bewässerungskreislauf) gerne planen und die Auswertung/Logik zur Bewässerung innerhalb Edomi durchführen. Wie sind Eure Erfahrungen mit den beiden Sensoren? Wertet ihr diese mit einem KNX-Analogeingang aus oder per RS485?

Wäre toll ein paar Erfahrungen zu hören.

Danke und viele Grüße,
Flo

[rdeckard]

gkamp Hallo Flo
Ich habe im letzten Herbst zwei SMT100 (RS485/ASCII) gekauft. Trotz des doppelten Preises gegenüber dem analogen SMT50 Sensor scheint mir dieser Typ sinnvoller zu sein. Ich habe kein Problem mit langen Kabeldistanzen (z.B. >20m), kann die Sensoren als Bus oder in einer Sternverkabelung verwenden und die Messdaten liegen in digitaler und somit auch präziser Genauigkeit vor (für Hobbyzwecke sicher nicht wichtig, aber ich ziehe halt ein genauer xx,x Wert einem ca. Wert vor).

Da wir im Herbst ein Teil unseres Gartens erneuert haben, sind die Sensoren noch nicht produktiv im Einsatz, jedoch bereits im Rasen und in einem Hochbeet vergraben. (Elektroverkabelung muss noch abgeschlossen werden.)
Ich konnte die Sensoren jedoch im Herbst etwas testen (provisorisch vergraben und verkabelt). Dazu habe ich einen bestehende Raspberry Pi 2/3 genommen und diese RS485 Platine gekauft (inkl. passendes Gehäuse). Damit kann man die Sensoren direkt an den Raspi anschliessen (durch den Bus können es beliebig viele Sensoren sein. Alles über ein 4-adriges Kabel). Jeder Sensor muss dazu einmalig mit einer eindeutigen ID programmiert werden. Erst dann kann man mehrere gleichzeitig anschliessen. Über das 4-adrige Kabel muss auch noch die Spannungsversorgung erfolgen (in meinem Fall 5V).

Sobald die Sensoren angeschlossen sind, kann man sie über ein einfaches Terminal-Programm ansprechen und mit paar wenigen Befehlen programmieren (ID) bzw. die Werte auslesen (Temperatur und Feuchte).
Ich habe mir dann zwei kleine Python-Scripts programmiert, welche auf dem Raspi im Hintergrund ständig laufen. Das eine Script ist ein Datenlogger, der alle 15 Min. alle Sensoren ausliest und die Werte mit Zeitstempel in ein lokales CSV-File schreibt. (Daraus könnte man dann natürlich Diagramme erstellen. Ich habs zum Testen bis jetzt nur mal im Excel ausgewertet, was sehr spannend war, weil man nun erstmalig sieht, wie und in welchem Zeitraum sich die Bodenfeuchtigkeit ändert.)

Das zweite Script ist ein kleiner Webserver, der ebenfalls die aktuellen Werte ausliest und in einer Webseite anzeigt. Das ist im Moment nur funktionell und nicht schön. Aber ich kann damit in meinem LAN von jedem Browser auf diese Werte zugreifen. Über diesen Weg werde ich später dann auch die Daten in Edomi bringen. Sind sie mal in Edomi, kann ich natürlich entsprechende Logiken für die Bewässerung bauen oder auch die Messwerte auf den KNX-Bus bringen.
Die Webseite sieht aktuell so aus (später kommen natürlich noch farbige Gauges):
smt100web.png

Für mich ist dies eine sehr flexible Lösung. Ich bin relativ frei in der Wahl der Hardware (mit Raspi und dem RS485 Shield sehr günstig), kann beliebig viele Sensoren anschliessen (die baugleiche Elsner KNX-only Lösung kostet weitaus mehr und kann nur 4 Sensoren pro Modul verarbeiten).
Und auch softwaremässig bin ich völlig offen. Ich kann den Raspi ohne KNX verwenden (Webserver/Datalogger ohne Bewässerungslogik), es in ein HA-System (z.B. Edomi) einbinden und über diesen Weg sogar ins KNX hinein.
Klar, es ist eine "Bastellösung" und benötigt etwas IT- und Programmierkenntnisse. Aber gerade das ist für mich der grosse Mehrwert (abgesehen von den geringeren Kosten). Ich kann z.B. eine Logik bauen, wie ICH es mir wünsche. Integriere ich z.B. noch die Wetterprognosen (z.B. Regen angesagt in den nächsten 3 Tagen), dann kann ich auf eine Bewässerung verzichten, obwohl der Schwellwert es bereits verlangt. Oder bei Wasserknappheit in einer langen Hitzeperiode würde ich dann alles auf Wassersparen optimieren etc. Man hat einfach soviele Möglichkeiten mehr, die vielleicht eine fertige, kommerzielle Lösung nie (oder nicht zahlbar) anbieten wird.

Aber ich bin noch nicht soweit. Mir gings mal um ein technisches Proof of Concept, ob ich mit diesen Mitteln die Daten auslesen kann. Das war erfolgreich. Rest ist halt eine Sache der eigenen Bedürnisse (und vorallem auch Zeit, dies umzusetzen).

[gkamp]

Hallo rdeckard,

1000 Dank für Deine tolle und ausführliche Antwort. Genau das schwebt mir auch vor und klingt nach einer optimalen Lösung. Eine Frage habe ich noch:

Wie verbindest Du mehrere Sensoren als Bus-Komponenten? Jeder Sensor hat doch nur die 4 Kabel, oder? Setzt Du dafür eine Verteilerdose o.ä. ein?

Danke und viele Grüße,
Flo

[damrein]

gkamp Hallo Flo
Ich habe im letzten Herbst zwei SMT100 (RS485/ASCII) gekauft. Trotz des doppelten Preises gegenüber dem analogen SMT50 Sensor scheint mir dieser Typ sinnvoller zu sein. Ich habe kein Problem mit langen Kabeldistanzen (z.B. >20m), kann die Sensoren als Bus oder in einer Sternverkabelung verwenden und die Messdaten liegen in digitaler und somit auch präziser Genauigkeit vor (für Hobbyzwecke sicher nicht wichtig, aber ich ziehe halt ein genauer xx,x Wert einem ca. Wert vor).

Da wir im Herbst ein Teil unseres Gartens erneuert haben, sind die Sensoren noch nicht produktiv im Einsatz, jedoch bereits im Rasen und in einem Hochbeet vergraben. (Elektroverkabelung muss noch abgeschlossen werden.)
Ich konnte die Sensoren jedoch im Herbst etwas testen (provisorisch vergraben und verkabelt). Dazu habe ich einen bestehende Raspberry Pi 2/3 genommen und diese RS485 Platine gekauft (inkl. passendes Gehäuse). Damit kann man die Sensoren direkt an den Raspi anschliessen (durch den Bus können es beliebig viele Sensoren sein. Alles über ein 4-adriges Kabel). Jeder Sensor muss dazu einmalig mit einer eindeutigen ID programmiert werden. Erst dann kann man mehrere gleichzeitig anschliessen. Über das 4-adrige Kabel muss auch noch die Spannungsversorgung erfolgen (in meinem Fall 5V).

Sobald die Sensoren angeschlossen sind, kann man sie über ein einfaches Terminal-Programm ansprechen und mit paar wenigen Befehlen programmieren (ID) bzw. die Werte auslesen (Temperatur und Feuchte).
Ich habe mir dann zwei kleine Python-Scripts programmiert, welche auf dem Raspi im Hintergrund ständig laufen. Das eine Script ist ein Datenlogger, der alle 15 Min. alle Sensoren ausliest und die Werte mit Zeitstempel in ein lokales CSV-File schreibt. (Daraus könnte man dann natürlich Diagramme erstellen. Ich habs zum Testen bis jetzt nur mal im Excel ausgewertet, was sehr spannend war, weil man nun erstmalig sieht, wie und in welchem Zeitraum sich die Bodenfeuchtigkeit ändert.)

Das zweite Script ist ein kleiner Webserver, der ebenfalls die aktuellen Werte ausliest und in einer Webseite anzeigt. Das ist im Moment nur funktionell und nicht schön. Aber ich kann damit in meinem LAN von jedem Browser auf diese Werte zugreifen. Über diesen Weg werde ich später dann auch die Daten in Edomi bringen. Sind sie mal in Edomi, kann ich natürlich entsprechende Logiken für die Bewässerung bauen oder auch die Messwerte auf den KNX-Bus bringen.
Die Webseite sieht aktuell so aus (später kommen natürlich noch farbige Gauges):
smt100web.png

Für mich ist dies eine sehr flexible Lösung. Ich bin relativ frei in der Wahl der Hardware (mit Raspi und dem RS485 Shield sehr günstig), kann beliebig viele Sensoren anschliessen (die baugleiche Elsner KNX-only Lösung kostet weitaus mehr und kann nur 4 Sensoren pro Modul verarbeiten).
Und auch softwaremässig bin ich völlig offen. Ich kann den Raspi ohne KNX verwenden (Webserver/Datalogger ohne Bewässerungslogik), es in ein HA-System (z.B. Edomi) einbinden und über diesen Weg sogar ins KNX hinein.
Klar, es ist eine "Bastellösung" und benötigt etwas IT- und Programmierkenntnisse. Aber gerade das ist für mich der grosse Mehrwert (abgesehen von den geringeren Kosten). Ich kann z.B. eine Logik bauen, wie ICH es mir wünsche. Integriere ich z.B. noch die Wetterprognosen (z.B. Regen angesagt in den nächsten 3 Tagen), dann kann ich auf eine Bewässerung verzichten, obwohl der Schwellwert es bereits verlangt. Oder bei Wasserknappheit in einer langen Hitzeperiode würde ich dann alles auf Wassersparen optimieren etc. Man hat einfach soviele Möglichkeiten mehr, die vielleicht eine fertige, kommerzielle Lösung nie (oder nicht zahlbar) anbieten wird.

Aber ich bin noch nicht soweit. Mir gings mal um ein technisches Proof of Concept, ob ich mit diesen Mitteln die Daten auslesen kann. Das war erfolgreich. Rest ist halt eine Sache der eigenen Bedürnisse (und vorallem auch Zeit, dies umzusetzen).

Welche Software hast du für das Programmieren der Sensoren und zum loggen der Sensoren im Raspberry genutzt?

[rdeckard]

Wie verbindest Du mehrere Sensoren als Bus-Komponenten? Jeder Sensor hat doch nur die 4 Kabel, oder? Setzt Du dafür eine Verteilerdose o.ä. ein?

Ich habe mich vorher natürlich auch bisschen in den RS485-Standard eingelesen und dabei viel von Bus-Abschlusswiderständen/Terminatoren etc. erfahren. RS485 wird in der Industrie für die serielle Übertragung verwendet (mit unterschiedlichen Protokollen, z.B. das bekannte ModBus). Dort werden normalerweise auch sehr hohe Übertragungsraten benutzt. In diesen Fällen muss der Bus auf beiden Seiten terminiert werden und Stichleitungen sind nicht erlaubt oder nur ganz Kurze.

Ich hatte mit dem Hersteller der Sensoren Mailkontakt und da wurde mir versichert, dass bei diesen Sensoren sehr tiefe Übertragunsraten (9600 Baud) verwendet werden, da hier ja eigentlich nur 2 Messwerte übertragen werden. Somit ist die Übertragungsqualität absolut tolerant. Man kann diese Sensoren also ohne Bus-Terminatoren und bis sicher 1000 m Länge ohne Probleme einsetzen. Stichleitungen, Sternverkabelung oder eben als Bus spielt keine Rolle. Man ist da in diesem Fall sehr frei.

Wie du dann die Verkabelung machst, hängt von deiner Gartensituation ab. Die Sensoren haben jeweils ein 10 m Kabel. (4-adrig, 2 für die Spannung und 2 für die Daten)
Wenn dein Raspi irgendwo in der Nähe ist (Keller, Anbau, Gartenhäuschen mit LAN/WLAN), kannst du das Kabel jeweils direkt zum Raspi führen und dort zusammenfassen und an den Raspi anschliessen (entspräche vom Kabel einer Sternverkabelung).
Du kannst aber natürlich auch im Garten die einzelnen Sensoren einfach hintereinander miteinander verbinden und am Ende mit einem einzigen Kabel zum Raspi gehen (das ist aktuell meine Situation, da ich dabei weniger Kabel vom Garten zum Raspi ziehen muss). Ggf. musst du halt im Garten eine kleine, wasserdichte Verteilerdose setzen.

[rdeckard]

Welche Software hast du für das Programmieren der Sensoren und zum loggen der Sensoren im Raspberry genutzt?

Ich habe in meinem Fall Python als Script-Sprache verwendet. Aber eigentlich kannst du jede Programmiersprache verwenden, mit der du auf die serielle Schnittstelle zugreifen kannst.
Die SMT100 Sensoren sind alle digital (RS485), aber es gibt sie in unterschiedlichen Ausführungen. Eine Variante verwendet für die Datenübertragung das in der Industrie häufig verwendete ModBus-Protokoll. Dann muss man sich aber bei der Programmierung zusätzlich noch mit diesem Protokoll auskennen bzw. beschäftigen.
Für mich war da die "ASCII"-Variante die einfachere. Hier werden wirklich nur ASCII-Daten über die serielle Schnittstelle bzw. dem Kabel geschickt. Das ist einfach zu verstehen, einfach zu testen und gut zu programmieren und reicht für diese Sensoren völlig aus. Also ich empfehle unbedingt die ASCII-Version zu bestellen!

Bevor ich mit der Script-Programmierung begann, habe ich einfach nur mit einem Terminal-Programm (ich habe minicom auf dem Raspi installiert) die paar wenigen Befehle ausprobiert. Im Auslieferungszustand haben die Sensoren keine ID (bzw. alle die ID 0). In diesem Fall kann man sie über die spezielle ID 0 ansprechen. Dafür darf man aber nur EINEN Sensor am Raspi angeschlossen haben, weil sonst ja nicht klar ist, welcher Sensor angesprochen werden kann.
Man kann bereits mit der ID 0 alle Befehle anwenden. Aber man sollte eigentlich schnell mal eine eindeutige ID setzen (z.B. ID 1, ID 2 etc.). Sobald ein Sensor eine ID hat, kann man den Sensor mit den gleichen Befehlen über diese ID ansprechen. Und dann dürfen natürlich auch mehrere Sensoren gleichzeitig angeschlossen sein.

Hier mein Spickzettel mit den Befehlen, wie ich es im minicom eingegeben habe:

GetTemperature!000000 > 28.2 (Nur mit EINEM Sensor ausführen!)
GetWaterContent!000000 > 0.0 (Nur mit EINEM Sensor ausführen!)
GetAddress! > (Nur mit EINEM Sensor ausführen!)
SetAddress!1 > 1 (Nur mit EINEM Sensor ausführen!)
GetTemperature!1 > 28.2
GetWaterContent!1 > 0.0

Wie du siehst, sind es eigentlich nur GET-Befehle (also lesend). Nur einmal braucht man einen SET-Befehl (schreibend), wenn man die ID setzen muss (oder ändern möchte).
So kannst du eigentlich manuell mit dem Sensor kommunizieren. Im späteren Script-Programm verwendet man einfach genau die gleichen GET-Befehle, nur dass dann das Script die serielle Schnittstelle öffnet und nicht das minicom-Terminal-Programm.

(Ich kann natürlich meine beiden Python-Scripts hier gerne zur Verfügung stellen. So als Basis, falls jemand mit Python arbeiten möchte.)

[damrein]

Ich habe in meinem Fall Python als Script-Sprache verwendet. Aber eigentlich kannst du jede Programmiersprache verwenden, mit der du auf die serielle Schnittstelle zugreifen kannst.
Die SMT100 Sensoren sind alle digital (RS485), aber es gibt sie in unterschiedlichen Ausführungen. Eine Variante verwendet für die Datenübertragung das in der Industrie häufig verwendete ModBus-Protokoll. Dann muss man sich aber bei der Programmierung zusätzlich noch mit diesem Protokoll auskennen bzw. beschäftigen.
Für mich war da die "ASCII"-Variante die einfachere. Hier werden wirklich nur ASCII-Daten über die serielle Schnittstelle bzw. dem Kabel geschickt. Das ist einfach zu verstehen, einfach zu testen und gut zu programmieren und reicht für diese Sensoren völlig aus. Also ich empfehle unbedingt die ASCII-Version zu bestellen!

Bevor ich mit der Script-Programmierung begann, habe ich einfach nur mit einem Terminal-Programm (ich habe minicom auf dem Raspi installiert) die paar wenigen Befehle ausprobiert. Im Auslieferungszustand haben die Sensoren keine ID (bzw. alle die ID 0). In diesem Fall kann man sie über die spezielle ID 0 ansprechen. Dafür darf man aber nur EINEN Sensor am Raspi angeschlossen haben, weil sonst ja nicht klar ist, welcher Sensor angesprochen werden kann.
Man kann bereits mit der ID 0 alle Befehle anwenden. Aber man sollte eigentlich schnell mal eine eindeutige ID setzen (z.B. ID 1, ID 2 etc.). Sobald ein Sensor eine ID hat, kann man den Sensor mit den gleichen Befehlen über diese ID ansprechen. Und dann dürfen natürlich auch mehrere Sensoren gleichzeitig angeschlossen sein.

Hier mein Spickzettel mit den Befehlen, wie ich es im minicom eingegeben habe:

GetTemperature!000000 > 28.2 (Nur mit EINEM Sensor ausführen!)
GetWaterContent!000000 > 0.0 (Nur mit EINEM Sensor ausführen!)
GetAddress! > (Nur mit EINEM Sensor ausführen!)
SetAddress!1 > 1 (Nur mit EINEM Sensor ausführen!)
GetTemperature!1 > 28.2
GetWaterContent!1 > 0.0

Wie du siehst, sind es eigentlich nur GET-Befehle (also lesend). Nur einmal braucht man einen SET-Befehl (schreibend), wenn man die ID setzen muss (oder ändern möchte).
So kannst du eigentlich manuell mit dem Sensor kommunizieren. Im späteren Script-Programm verwendet man einfach genau die gleichen GET-Befehle, nur dass dann das Script die serielle Schnittstelle öffnet und nicht das minicom-Terminal-Programm.

(Ich kann natürlich meine beiden Python-Scripts hier gerne zur Verfügung stellen. So als Basis, falls jemand mit Python arbeiten möchte.)

Das wäre nett... bin nicht der high end entwickler und dachte das es mit einer Standard Software gelöst worden wäre...

[Robby]

damrein
Vollzitate werden laut Forenregeln nicht gern gesehen!

[vento66]

damrein Kannst Du mal aufhören hier ständig die Zitatfunktion als "Antwortbutton" zu missbrauchen? Das kann ja kein Mensch mehr lesen!

[damrein]

...

[bluegaspode]

Ich würde das über diesen Weg nicht empfehlen, wenn man keine Programmierkenntnisse hat.
Dann doch lieber mit dem SMT50 zufrieden geben, und das Signal auf einen einfachen Analogeingang.

Bei mir funktioniert diese Lösung gut genug. Edomi wird verwendet, um die Spannung in den Bodenfeuchtegrad umzuwandeln.
Am Ende konfiguriert man ja dann nur einen Schwellwert für "zu trocken" und lässt darauf dann eine Logik laufen.

[rdeckard]

bluegaspode Du hast sicher recht, dass der SMT50 in den meisten Fällen für Privatzwecke reicht. Mich haben einfach die Probleme einzelner User mit Kabellängen >25m etwas gestört, weil ich auch auf lange Kabel angewiesen wäre. Und generell die Rauschanfälligkeit der analogen Methode.
Wenn jemand keine IT- bzw. Programmierkenntnisse besitzt, dann würde ich ihm aber auch eher die SMT50 oder gar die Elsner Lösung empfehlen.

Ich bin aber auch kein Profiprogrammierer und meine (bereits funktionierenden) Scripts dienen ja nur dem Auslesen der Werte. Mehr sollen diese Scripts ja nicht können. Die noch zu erstellende Logik (mit was für einem Tool auch immer), muss ja in beiden Fällen (SMT50 wie auch SMT100) noch zusätzlich erstellt werden. Gerade wenn man evtl. noch Wetterkurzzeitprognosen berücksichtigen möchte. Das alleine geht ja vermutlich auch nicht ganz ohne "Programmierkenntnisse". Man muss sich schon bewusst sein, dass wir hier nicht von einer Plug'n Play Lösung sprechen. Dieses ganze Forum spricht ja vorallem Leute an, die selber etwas mit KNX oder Drittsystemen individuell aufbauen möchten.


Wie sind eigentlich unterdessen deine Erfahrungen mit deinem Schwellwert? Du hast ja mal was erwähnt, dass du mit einem Schwellwert von 15 oder 20 rechnest. Hat sich dies nun bei dir so eingependelt? (Ich weiss, diese Werte sind nicht übertragbar)
Ich frage nur, weil ich ja mein Sensor (für den Rasen) diese Woche das erste Mal angeschlossen habe. Dabei hat er mir ein Wert von 14% angezeigt. Bei uns herrscht seit Wochen grosse Trockenheit und seit einigen Tagen fast schon sommerliche Temperaturen. Ich habe dieses Jahr noch nie den Rasen bewässert, somit interpretiere ich diese 14% bei meinem Rasen als ein Schwellwert für "zu trocken". (obwohl der Rasen noch mehrheitlich grün ist, ist aber auch erst im letzten September neu angelegt worden.) Damit liege ich eigentlich sehr nahe an deinem Schwellwert.

Ich habe dann vorgestern Abend zum Testen meine Bewässerung manuell ca. 3,5 Std. laufen lassen. Während dieser 3,5 Std. sind die Werte praktisch stabil geblieben (es braucht halt seine Zeit, bis das Wasser wirklich runtersickert). Erst nach der Bewässerung gingen die Werte rauf. Und zwar über die ganze Nacht hinweg. Ich hatte leider den Datenlogger nicht aktiviert, aber am folgenden Vormittag hatte ich einen Höchstwert von über 26%, der seitdem nur ganz langsam wieder runter geht. (Das ist glaub das, was du auch unter deinen 30% beobachtet hast).
Vor 24 Std. hatte ich noch ein Wert von 25,64%, jetzt 23,76%. D.h. die Feuchtigkeit ist innerhalb von 24 Std. um 1,88% gesunken, was pro Std. ca. 0,078% ausmacht. (Die Kurve ist aber nicht linear)
Ich bin also gespannt, wie lange es dauert, bis ich wieder bei der Ausgangslage von 14% bin. (Müsste ja über 5 Tage sein, aber ich denke, dass es schneller trocken wird.)
Das ist jetzt nur mal eine erste (interessante) Erkenntnis und natürlich noch lange keine Langzeiterfahrung. (Auch haben wir aktuell immer noch Nachttemperaturen im einstelligen Bereich. Wird spannend, wie sich das dann im Hochsommer zeigt.)

Was man dann aus diesen Erfahrungen interpretiert, ist eine andere Sache. Ist es evtl. wassersparender, wenn man immer im Bereich von über 20% bleibt oder sollte man einfach einmal pro Woche von 14% auf 26% bewässern. Und wie lange kann/soll man den Rasen im 14% Bereich belassen. (Aktuell habe ich diesen Wert ja wohl schon seit ein paar Wochen ohne direkte Auswirkungen auf den Rasen. Ausser ein paar braune Randstellen.)

Aber das ist genau das, was mir an solch einer Lösung so gefällt. Man kann Ursache/Wirkung direkt beobachten und somit optimieren.

[bluegaspode]

Hier meine aktuellen Grafen. Aus irgendeinem Grund sind seit heute Nacht die Werte ausgefallen.
Bildschirmfoto 2020-04-13 um 15.05.00.png

Wenn es hoch geht, ist es die Bewässerung (bei mir 2mal in der Nacht, da habe ich noch manuell angestellt).
Der Sensor ist bei mir nur 5cm tief eingebuddelt, das Wasser kommt relativ zügig beim Senser an (30-60min Delays) ... und wie du siehst ist der Effekt nach 24h auch schon wieder weg.

Automatische Bewässerung teste ich bei mir weiterhin zwischen Werten von 18-20%.
Aktuell aktiviere ich noch ein paar mal manuell, da frisch vertikutiert und gedüngt.

[gkamp]

Du kannst aber natürlich auch im Garten die einzelnen Sensoren einfach hintereinander miteinander verbinden und am Ende mit einem einzigen Kabel zum Raspi gehen (das ist aktuell meine Situation, da ich dabei weniger Kabel vom Garten zum Raspi ziehen muss). Ggf. musst du halt im Garten eine kleine, wasserdichte Verteilerdose setzen.

rdeckard Hi, genau das schwebt mir auch vor: 4-5 Sensoren hintereinander zu schalten, um mit einem Kabel zur Station zu gehen. Wie hast Du die einzelnen Sensoren denn verbunden/in Reihe gelegt? Dafür musst Du doch die Kabel im Garten irgendwie/irgendwo wasserdicht verklemmen... Wäre nett, wenn Du mir dazu einen kurzen Hinweis geben kannst.

Ansonsten ist die Lösung super.

Danke und viele Grüße,
Flo