OpenSprinkler

[wintermute]

Hast Du vor die LBS anzupassen?

Vom datum her wuerde ich schaetzen, da lag die 2.17er Firmware als Grundlage vor. Ich werde das anpassen, kann aber etwas dauern, ich muss mich erst wieder ins Opensprinkler-Thema reinlesen. Vermutlich ist es aber wohl kein grosses Ding...

[vento66]

Ist es auch nicht die Regensensoren sind umbenannt worden, und noch ein, zwei Sachen hinzugekommen.

[saegefisch]

Als ich letztes Jahr meinen Garten-UV (innen) komplett fertig konzipiert und verkabelt habe, hatte ich OpenSprinkler (OS) leider nicht auf dem Schirm. Derzeit habe ich dort für 6 Magnetventile einen KNX-Aktor fertig belegt inkl. 24V-Versorgung - alles nach draußen gelegt (auf außen-UV in Garage nur mit Reihenklemmen). Dort fehlen jetzt nur noch die Ventile (Hunter ist geplant). Für Bodenfeuchte hatte ich an 1-wire gedacht oder irgend eine ESP2866/Wimo D1-Lösung per MQTT - aber bisher nur theoretisch.

Logik wäre edomi: Nach Zeitplan, ggf. aussetzen bei hoher Bodenfeuchte oder hoher Regenwahrscheinlichkeit oder tatsächlichem Regen (z-B. aus DWD-Rückblick stündlich). Ich kann damit leben, dass ich bei Regen zu viel bewässere, da ohnehin aus Zisterne. Sequentielle Folge der Ventile liefe über Sequenzen, damit Druck/Wassermenge reicht. Hört sich auf den ersten Blick machbar an und nicht zu kompliziert.

Nun stoße ich wieder auf diesen Threat - und habe Fragen bzw. komme ins Grübeln:
* Welchen Mehrwert schafft OS tatsächlich der edomi-Lösung gegenüber?
* Lohnt es der Mehrwert, den bereits gekauften KNX-Aktor raus zu hauen und stattdessen den OS-Modul für 8 Kanäle zu kaufen für ~ 220€ und außen neben den Ventilen zu montieren?
* Gibt es eine sinnvolle Logik-Ergänzung, den OS von Hause aus nicht abdeckt und von Euch in edomi gebaut wird? Hier hat ja der ein oder andere schon längerer OS-Erfahrungen gesammelt.

Mir ist klar, dass man mit jeder Lösung alles erreichen kann - meine Frage meint daher die ehrliche Einschätzung, was Euch sinnvoll erscheint in dieser Ausgangslage.

PS: Nicht für meine Frage relevant, aber zur Info - in der aktuellen ct stand, dass OS in der beta wohl MQTT-Anbindung erprobt.

[vento66]

Lass OS Doch auf einem PI laufen, und richte die Stationen als http ein. Dann kannst alles so lassen, und nutzt die Wetterberechnungen etc von OSPI, und steuerst den Aktor mittel EDOMI. Läuft hier gerade testweise so, wobei das Grundstück mit dem Rasen 50km entfernt ist, und der Raspi hier auf dem Schreibtisch liegt.

[starwarsfan]

Hast Du aber eine lange Leitung!

SCNR

[vento66]

2.... der örtliche Regensensor wird auch von dort hierher gemeldet

[saegefisch]

Lass OS Doch auf einem PI laufen, und richte die Stationen als http ein

* Habe keinen RasPi herum liegen - müsste eigens dafür einen kaufen - zusammen mit dem OS-Board und Gehäuse/SD kommt man fast auf den Preis des OS-Fertggeräts. Da würde ich das Fertiggerät bevorzugen: 24V von vorhandem NT und fertig.
* http...verstehe ich Dich richtig: Ventile und Regensensor wie von mir angedacht alles an edomi anschließen. OS würde per API quasi eine augelagerte Beregnungs-Logik, edomi ist nur noch Durchlauf zu den Aktoren.

Alternativ wäre ja immer noch, dass die Ventile außen an OS direkt anschließe. Noch mal die Frage: Welchen tatsächlichen Mehrwert hat OS gegenüber Sequenzen, ZSU und etwas Aussetz-Logik bei Regen und/oder Bodenfeuchte? Ich will in keiner Weise OS klein reden, sondern ich frage mich wirklich von den Beschreibungen her, was es mehr macht als das.

[vento66]

Die Ganze Anpassung der Beregnungszeiten, nach der Niederschlagsmenge incl Wettervorhersage ist schon fertig. Ausserdem kannst Die Programme anlegen, und bei Bedarf aktivieren / deaktivieren. In EDOMI musst halt alles über Sequenzen etc. lösen. Dort ist alles schon fertig. Kommt jetzt auch mit MQTT Anbindung. Den Rest hast schon richtig verstanden. Dann würde ich die Ventile direkt anschliessen (solange Du nicht mehr als 8 hast).

[ruppsn]

Noch mal die Frage: Welchen tatsächlichen Mehrwert hat OS gegenüber Sequenzen, ZSU und etwas Aussetz-Logik bei Regen und/oder Bodenfeuchte? Ich will in keiner Weise OS klein reden, sondern ich frage mich wirklich von den Beschreibungen her, was es mehr macht als das.

Kurz und knapp: keinen Mehrwert, wenn es rein um die Funktionalität gibt. Sicher kannst Du mit der Logikengine von Edomi und KNX das auch alles hinbekommen. Wie vento66 schon sagte, beim OS ist halt alles fertig, praxiserprobt und funktioniert einfach. Es gibt ein Webinterface und damit einen Fernzugriff ohne an irgendeine Cloud angebunden zu sein. Die MQTT Anbindung ist meines Wissens eher spärlich, allerdings gibt es auch eine HTTP API mit der man OS komplett fernsteuern kann. Ist vielleicht vergleichbar mit der Frage: Beschattungsautomatik eines Jalousie-Aktors nutzen oder mit Edomi (LBS) selbst machen.

Meine Überlegung war bspw. dass ich möglichst schnell eine Lösung haben wollte, die funktioniert und sowohl aus Edomi (Tablet an der Wand) und per App / Webbrowser (Handy/Rechner) steuerbar ist. Aktuell habe ich einfach das Webinterface von OS in Edomi per Web-Visuelement eingebunden und kann die Bewässerung komplett darüber steuern. Passt auch optisch so einigermaßen zur Visu, wobei eine individualisierte, optisch noch schönere Version dann im Winter kommt - dann über MQTT / Web-API. Um einen vergleichsweise reichhaltigen Funktionsumfang komplett mit Edomi und KNX zu erreichen, hätte ich ungleich mehr Aufwand reinstecken müssen. Das war es mir aktuell nicht wert, ist aber natürlich eine sehr subjektive Abwägung.

[vento66]

Ich hab da eh gerade 2 LBS für die Steuerung /Status in der Mache.

[ChrisChros]

Ich hab da eh gerade 2 LBS für die Steuerung /Status in der Mache.

Hallo vento66 ist das Projekt mit den 2 LBS für OpenSprinkler noch aktiv?

[vento66]

Steht im Moment on hold, aber der Sommer kommt ja wieder.

[ChrisChros]

Aktuell versuche ich OpenSprinkler mittels MQTT auszulesen, aber irgendwie bekomme ich das nicht richtig hin.
Wenn ich z.B. opensprinkler/# als subscribe wähle bekomme ich als Antwort nur zurück das OpenSprinkler online ist, aber keinen status das z.B. ein Beregnungskreis gerade aktiv ist.
Würde es auf jedenfall begrüßen wenn es zur der MQTT Möglichkeit noch eine Alternative geben würde.

[vento66]

Also MQTT funktioniert. für die Stationen hab ich ein

opensprinkler/station/#

am MQTT parser, und dann als Wildcard 1 (Oder halt die Nummer der Station). Das ganze dann auf einen json extraktor der state und duration ausgibt.

[ChrisChros]

dann muss ich wohl noch etwas testen. dank dir.
noch eine Fragen zum Verständnis, muss ich dann an jeden Ausgang des parsers den json-decoder verbinden?